Стали бы вы когда-нибудь создавать отношения на основе естественного идентификатора или использовать внутренний идентификатор и эмулировать отношения с естественным идентификатором?[дубликат]

Question

Возможный дубликат:
Суррогатное материнство против.Природные/Деловые ключи

Если даны две таблицы, Level1 [ID, Title, Number] Level2 [ID, FKID???, Title, Number]

Пользователь системы понимает, что уровень 2 связан с уровнем 1 на основе номера уровня 1. Мой вопрос к вам заключается в следующем: вы создадите связь на основе внутреннего идентификатора и «эмулируете» связь с «номером» или вы просто используете Поле «Число» и покончить с этим?

Answer 1

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

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

Answer 2

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

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

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

Тем не менее, если бы я пошел по пути суррогатного ключа, я бы настроил таблицы следующим образом.

Level1 [ID, Title, Number] Level2 [ID, FKID references Level1]

Нет необходимости сохранять название и номер дважды.

Answer 3

Думаю, об этом говорилось много раз.

Почти всегда безопаснее использовать IDENTITY/AUTONUMBER в качестве внешнего ключа.

Большинство естественных ключей можно дублировать (даже если по ошибке).

В моей стране даже есть проблемы с личными идентификационными номерами людей X-).

Answer 4

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

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

Все сводится к семантике столбца «Число».

Answer 5

• Иногда лучше всего использовать естественный ключ если (Например, SSN или идентификатор сотрудника) Вы уверены в стабильности ключа.

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

• Другие авторы комментировали беспорядок, который происходит, когда приходится менять естественный ключ.Конечно, это проблема.Но стоит проверить, как часто эти исключения будут случаться у вас — должен ли хвост (исключения) вилять собакой (ваш дизайн) — в каждом случае?

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

• Если естественным ключом является множество полей, скажем, DateOfBirth + Lastname + отдел (или что -то вроде такого странного), то вам лучше использовать искусственные ключи.

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