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

Question

Какой метод является лучшим и Почему ?

a) Таблица типов, суррогатный / искусственный ключ

Внешний ключ от user.type до type.id:

b) Таблица типов, натуральный ключ

Внешний ключ от user.type до type.typeName:

Answer 1

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

Ниже перечислены основные недостатки подхода с использованием естественного ключа:

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

• Индекс для поля int будет намного более компактным, чем индекс для поля varchar.

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

Answer 2

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

Answer 3

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

Answer 4

Хорошей причиной для использования суррогатного ключа (вместо естественного ключа, такого как имя) является случай, когда естественный ключ не является хорошим выбором с точки зрения уникальности. За свою жизнь я знал не менее 4 "Криса Смита". Имена людей не являются уникальными.

Answer 5

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

Answer 6

Если typeName является естественным ключом, то это, вероятно, предпочтительный вариант, поскольку для получения значения не требуется объединение.

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

Answer 7

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

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

UserId varchar(20), ID int, Name varchar(200)

в качестве структуры таблицы.

теперь учтите, что я хочу отслеживать во многих таблицах то, кто вставляет записи ... если я использую Id в качестве первичного ключа, тогда [1,2,3,4,5..] и т. Д. Будут находиться во внешних таблицах и всякий раз, когда яМне нужно знать, кто вставляет данные, я должен присоединиться к ней, потому что 1,2,3,4,5,6 не имеет смысла.но если я использую UserId в качестве первичного ключа, который уникально идентифицирован, то в других внешних таблицах [john, annie, nadia, linda123] и т. д. будут сохранены, что иногда легко различимо и имеет смысл.поэтому мне не нужно присоединяться к пользовательской таблице каждый раз, когда я делаю запрос.

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

Answer 8

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

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

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

Answer 9

Суррогатный ключ для меня тоже, пожалуйста.

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

Answer 10

Суррогатный ключ является заменой естественного первичного ключа.Это просто уникальный идентификатор или номер для каждой строки, который можно использовать для первичного ключа таблицы.Единственное требование к суррогатному первичному ключу состоит в том, что он уникален для каждой строки в таблице.

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