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

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

кажется действительно ненужным вводить новый суррогатный ключ к этим таблицам, или?

В общем, каковы исключительные случаи, когда суррогатные ключи не должны использоваться?

9
database-design primary-key

6 ответов

Я бы сказал, что должны быть соблюдены следующие критерии:

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

  • ваш естественный ключ должен быть таким же маленьким, как INT, например, не значительно больше, чем 4 байта в размере (не используйте VARCHAR (50) для вашего ПК, и особенно не для вашего ключ кластеризации в SQL Server !)

  • ваш естественный ключ должен быть стабильным, например, никогда не меняться (хорошо, с кодами стран ISO, это почти дано - за исключением случаев, когда такие страны, как Югославия или распад СССР, или другие, как две Германии, объединяются - но это достаточно редко)

Если эти условия выполнены, вы можете рассматривать естественный ключ как ваш PK - но это должно быть исключением 2% во всех ваших таблицах - не норма.

21

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

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

3

естественные ключи (коды стран в вашем случае) лучше, потому что

  • Они имеют смысл, когда вы видите их (один суррогатный ключ ничего не значит для пользователя. Это важно для разработчиков БД и сопровождающих, которым часто приходится работать с необработанными выходами БД)
  • меньше соединений (часто вам нужен только код страны, и они уже находятся в других таблицах. Если вы используете суррогатные ключи, вам нужно будет присоединиться к таблице поиска)

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

Итак, если в вашей БД логика не меняется в течение многих лет, используйте естественные ключи.

2

есть давние дебаты по этому поводу. Если вы google для "surrogate V natural keys", вы получите много ссылок. Поэтому я подозреваю, что вы получите дискуссию, а не четкий ответ здесь.

с в этой статье:

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

2

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

0

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

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

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

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

0