Может ли таблица SQL иметь несколько столбцов с первичным ключом?

Ответ 1

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

Ответ 2

В таблице может быть только одно ограничение первичного ключа, но это может состоять из нескольких столбцов, например.

create table my_table (col1 integer, col2 integer, col3 integer,
   primary key (col1, col2, col3)
   );

В дополнение к первичному ключу таблица может также иметь одно или несколько ограничений UNIQUE, например

create table my_table2 (col1 integer, col2 integer, col3 integer,
   primary key (col1, col2),
   unique (col2, col3)
   );

Ответ 3

Если вы спрашиваете, может ли таблица иметь несколько столбцов в качестве первичного ключа, то для MS SQL Server ответ да, и он называется составным (исправленным) ключом.

Ответ 4

"Обычно сложный ключ - это плохая практика".

Остерегайтесь лжепророков, которые пытаются продать вам такое дерьмо.

Ключ - это ключ, ключ - это ключ. Ключ - это набор атрибутов. Не больше, не меньше. Мощность этого набора может быть 1 или может быть > 1, и она может EVEN BE ZERO! И ключ соответствует, один на один, к некоторому ограничению уникальности.

Реляционная модель НЕ ПРЕДНАЗНАЧЕНА, ЧТО ТАКОЕ, что ограничение ключа/единственности может включать только один атрибут.

Кроме того, и у реляционной модели нет каких-либо предположений о том, что когда-либо против наличия более одного ключа, и ДАЖЕ факт, что реляционная теория отбросила концепцию (уже на протяжении десятилетий) "первичного ключа" (подразумевая, что такой "первичный" ключ в любом случае был бы "более ключевым", чем другие), потому что совершенно ненужный и неактуальный. Что касается уникальности, которую подразумевают ключи, ВСЕ КЛАВИКИ РАВНО (и это не тот случай, когда один конкретный ключ больше, чем другие).

Ответ 5

Обычно сложный ключ является плохой практикой. Это приведет к замедлению работы, когда вам нужно присоединиться к нему. Это также сложнее, если вам нужно обновить одно или несколько полей в 27 дочерних таблицах. Лучшей практикой является суррогатный ключ и уникальный индекс в полях, которые обычно составляют составной ключ. Затем у вас есть скорость целочисленного соединения и сохраняется уникальный атрибут, а когда значение ключа изменяется (как это часто бывает в составном ключе), вам нужно изменить только одну таблицу, а не все дочерние таблицы.

Есть одно место, где я буду использовать составной ключ, хотя и это таблица отображения, которая используется для создания отношений для отношений "многие ко многим". В этом случае у вас обычно есть только два столбца, и оба они обычно являются целыми числами, которые обычно не меняются. Затем я обычно использую составной ключ, так как этот конкретный случай не имеет недостатков, которые композит имеет в обычной таблице.