SQL: столбец первичного ключа. Искусственный столбец «Id» против «Природные» столбцы

Question

Можно создать дубликат:
Relational database design question - Surrogate-key or Natural-key?

При создании реляционной таблицы есть соблазн выбрать столбец первичного ключа столбец, значения которых являются уникальными , Но для целей оптимизации и единообразия я каждый раз создаю искусственный столбец ИД. Если есть столбец (или комбинация столбцов), который должен быть уникальным, я создаю для него уникальный указатель вместо того, чтобы маркировать их как (составные) столбцы первичного ключа.

Действительно ли это хорошая практика всегда предпочитать искусственный столбец «Id» + индексы вместо натуральных столбцов для первичного ключа?

Answer 1

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

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

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

С точки зрения согласования запросов и именования я также предпочитаю синтетические ключи, потому что приятно знать, когда вы соединяете таблицы, что первичный ключ A будет A_ID, а первичный ключ B - будет B_ID. Это гораздо более самодокументируемо, чем попытка запомнить, что первичный ключ A - это комбинация A_NAME и A_REVISION_NUMBER, а первичный ключ B - B_CODE.

Answer 2

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

Answer 3

Предпочитаю всегда использовать искусственный ключ.

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

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

Answer 4

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

Некоторые люди будут использовать, например, значимые уникальные значения для бизнеса в качестве своего идентификатора таблицы, и я уже прочитал на MSDN и даже в официальной документации NHibernate, что предпочтение отдается уникальному бизнес-значению (искусственный идентификатор) вы хотите создать индекс для этого значения для дальнейшего использования. Итак, в день, когда компания изменит свою номенклатуру, система все равно будет работать безупречно.

Answer 5

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

• Small - меньше ключ, тем больше значения вы можете получить в одну строку, и тем быстрее индексировать сканирование будет
• Неуклонно растет - производит меньше индекса перестановки по мере роста таблицы, улучшение производительности.

Answer 6

Существует небольшое различие между ключом, принудительно выполняемым с помощью ограничения PRIMARY KEY, и ключ, принудительно выполняемый с помощью ограничения UNIQUE. Важно то, что вы выполняете ВСЕ ключи, необходимые с точки зрения целостности данных. Обычно это означает, что не менее один «натуральный» ключ (ключ, открытый пользователям/потребителям данных и используемый для идентификации фактов о вселенной дискурса) в таблице.

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