Мне действительно нужен PRIMARY KEY при использовании столбцов UNIQUE NOT NULL? - PullRequest
Новая
       71

Мне действительно нужен PRIMARY KEY при использовании столбцов UNIQUE NOT NULL?

0 голосов
/ 09 сентября 2018

Мои знания в области SQL ограничены, и я был бы признателен за помощь в разъяснении использования PRIMARY KEY в следующих обстоятельствах. Я создал таблицу для поддержки информации о стране ISO. Я использую MariaDB 10, но считаю, что это не будет актуально для тех вопросов, которые у меня есть (?) 

CREATE TABLE IF NOT EXISTS python.country
(
   iso_code    INTEGER(   3) NOT NULL     ,
   iso_2_alpha VARCHAR(   2) NOT NULL     ,
   iso_3_alpha VARCHAR(   3) NOT NULL     ,
   short_name  VARCHAR(  32) NOT NULL     ,
   long_name   VARCHAR(  64) NOT NULL     ,
   flag_link   VARCHAR(2000) DEFAULT(NULL),

   CONSTRAINT  CK_iso_code       CHECK       (iso_code > 0 AND iso_code <= 999)                                ,
   CONSTRAINT  CK_iso_alpha      CHECK       (
                                              iso_2_alpha RLIKE BINARY '^[A-Z]+$' AND LENGTH(iso_2_alpha) = 2 
                                              AND 
                                              iso_3_alpha RLIKE BINARY '^[A-Z]+$' AND LENGTH(iso_3_alpha) = 3
                                             )                                                                 ,  
   CONSTRAINT  CK_names          CHECK       (
                                              short_name RLIKE '^\\p{L}+(\\.?[[:blank:]]\\p{L}+)*\\p{L}+$'
                                              AND 
                                              long_name  RLIKE '^\\p{L}+(\\.?[[:blank:]]\\p{L}+)*\\p{L}+$'
                                             )                                                                 ,
   CONSTRAINT  UN_short_name     UNIQUE      (short_name)                                                      ,
   CONSTRAINT  UN_long_name      UNIQUE      (long_name)                                                       ,
   CONSTRAINT  UN_iso_2_alpha    UNIQUE      (iso_2_alpha)                                                     ,
   CONSTRAINT  UN_iso_3_alpha    UNIQUE      (iso_3_alpha)                                                       
   -- ???
   -- CONSTRAINT  PK_country        PRIMARY KEY (iso_code,iso_2_alpha,iso_3_alpha)

); -- ENGINE = 'InnoDB';

Вопрос 1: Поскольку все основные столбцы (iso_code, iso_2_alpha, iso_3_alpha) имеют значения NOT NULL и UNIQUE, имеет ли смысл создавать составной PRIMARY KEY? Я "верю", что это пустая трата пространства и времени при вставке новых элементов?

Вопрос 2: Можно ли безопасно использовать iso_code, если в другой таблице указан FOREIGN KEY?

Большое спасибо.

Ответы [ 2 ]

0 голосов
/ 09 сентября 2018

Так как все основные столбцы (iso_code, iso_2_alpha, iso_3_alpha) НЕ НУЛЬЫ и UNIQUE имеет смысл создавать составной ПЕРВИЧНЫЙ КЛЮЧ?Я «верю», что это пустая трата пространства и времени при вставке новых элементов?

Ваш предложенный PK - суперключ над существующими ключами.Это не обязательно само по себе.Вы можете вместо этого объявить одно из ваших уникальных ключевых ограничений как PK, но это не обязательно.

Могу ли я безопасно использовать iso_code, если в другой таблице используется FOREIGN KEY?

Если вы также пометите iso_code как уникальный ключ в этой таблице, это должно работать нормально.

Некоторые люди рекомендуют, чтобы в каждой таблице всегда был автоматически сгенерированный столбец, помеченный как PK.Это нормально, если вы также применяете логические ключи.К сожалению, многие люди просто создадут этот авто-ПК и никаких других ключей, а это значит, что ваши данные бессмысленны.

Вы выбрали (в настоящее время) просто иметь логические ключи.Я думаю, что это нормально в этом случае, тем более, что некоторые (iso_code, iso_2_alpha и iso_3_alpha), вероятно, будут более компактными, чем рекомендуемая автоматически генерируемая колонка.

0 голосов
/ 09 сентября 2018

Не могу прокомментировать производительность и эффективность, но одна вещь с составными ключами состоит в том, что когда вы используете их в качестве первичного ключа, вы должны повторять их в своем внешнем ключе. То есть PK iso_code, iso_2_alpha, iso_3_alpha будут дополнительными столбцами FK во всех связанных таблицах. Затем вы также должны запросить эти 3 столбца в ваших запросах SQL. Немного из PITA IMO, когда вы можете просто использовать общий, уникальный самогенерирующий столбец.

Если вы можете использовать iso_code и уверены, что у вас никогда не будет возможности потребовать вставки дубликата iso_code с другим iso_2_alpha, тогда iso_3_alpha, тогда продолжайте. Но вы должны быть в будущем и сделать таблицу более надежной и предвидеть непредвиденные ситуации, используя новый выделенный столбец идентификаторов, не связанный с бизнесом, ИМХО.

...