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

Ответ 1

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

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

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

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

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

Ответ 9

Ну, я думаю, что ключ surrgote полезен, когда у вас нет однозначно идентифицированного ключа, значение которого связано и имеет смысл, так как это его первичный ключ... Кроме того, ключ 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 сохраняется в чужих таблицах, который берет дополнительные байты.. и индексирование incourse имеет значительную проблему с производительностью, где int работает лучше, чем varchar

Ответ 10

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

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