SQL: первичному ключу или нет первичному ключу?

Question

У меня есть таблица с наборами настроек для пользователей, в ней есть следующие столбцы:

UserID INT
Set VARCHAR(50)
Key VARCHAR(50)
Value NVARCHAR(MAX)
TimeStamp DATETIME

UserID вместе с Set и Key являются уникальными. Таким образом, конкретный пользователь не может иметь две одинаковые клавиши в определенном наборе настроек. Настройки извлекаются с помощью набора, поэтому, если пользователь запрашивает определенный ключ из определенного набора, загружается весь набор, так что в следующий раз, когда потребуется ключ из того же набора, он не должен идти в базу данных. .

Должен ли я создать первичный ключ во всех трех столбцах (идентификатор пользователя, набор и ключ) или создать дополнительное поле с первичным ключом (например, целочисленное значение автоинкремента с именем SettingID, я думаю, плохая идея) или нет создать первичный ключ и просто создать уникальный индекс?

----- ОБНОВЛЕНИЕ -----

Просто чтобы прояснить ситуацию: это конец таблицы строк, в любом случае он не объединен. UserID - это FK для таблицы Users. Набор не ФК. Это в значительной степени вспомогательная таблица для моего графического интерфейса. Просто в качестве примера: пользователи получают в первый раз, когда они посещают части сайта, всплывающую подсказку, которую они могут закрыть, если захотят. Как только они его щелкнули, я добавлю некоторые настройки в набор «GettingStarted», в которых будет указано, что helpballoon X отключен. В следующий раз, когда пользователь зайдет на ту же страницу, в настройке будет указано, что всплывающая подсказка X больше не должна отображаться.

Answer 1

Наличие составных уникальных ключей в большинстве случаев не очень хорошая идея.

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

Лучше всего создать суррогатный ключ, автоматический номер, который не имеет никакого делового значения.

Редактировать после обновления:

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

Answer 2

Должен ли я создать первичный ключ для всех трех столбцов (userid, set, and key)

Сделай это.

Использование суррогатного первичного ключа приведет к появлению дополнительного столбца, который не будет использоваться для других целей.

Создание UNIQUE INDEX вместе с суррогатным первичным ключом аналогично созданию некластеризованного PRIMARY KEY и приведет к дополнительному KEY lookup, что ухудшает производительность.

Создание UNIQUE INDEX без PRIMARY KEY приведет к таблице HEAP-organized, для которой потребуется дополнительный RID lookup для доступа к значениям: тоже не очень хорошо.

Answer 3

Сколько у тебя Ключей и Сета? Должны ли они быть varchar (50) или они могут указывать на таблицу поиска? Если вы можете преобразовать этот Set и Key в SetId и KeyId, вы можете создать свой первичный ключ на 3 целочисленных значениях, что будет намного быстрее.

Answer 4

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

Answer 5

Лучше иметь UserID как 32-битный newid () или уникальный идентификатор, потому что UserID как int дает пользователю подсказку о вероятном UserID. Это также решит проблему составного ключа.

Answer 6

По моему опыту все зависит от того, сколько таблиц будет использовать эту таблицу в качестве информации FK. Хотите ли вы, чтобы три дополнительных столбца в других ваших таблицах были перенесены на ФК?

Лично я бы создал еще один столбец FK и наложил бы уникальное ограничение на остальные три столбца. Это делает внешние ключи к этой таблице намного легче глотать.

Answer 7

Создать один, отдельный первичный ключ. Независимо от того, как изменится логика бизнеса, какие новые правила нужно будет применить к полю Key VARCHAR (50) - наличие одного первичного ключа сделает вас полностью независимым от логики бизнеса.

Answer 8

Я бы, вероятно, попытался убедиться, что UserID был уникальным идентификатором, а не иметь дубликаты UserID во всем коде. Композитные ключи могут запутаться позже в жизни вашего кода.

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