Собственный первичный ключ или автоматически сгенерированный?

Question

Как правило, лучше использовать собственные первичные ключи (т. Е. Существующие столбцы или комбинацию столбцов) или установить для первичного ключа автоматически генерирующую строку целых чисел?

EDIT:
Мне было указано, что это очень похоже на этот вопрос .

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

Хотя ответы здесь все полезны, большинство из них основаны на субъективном «здесь то, что вы должны» и не приводят вспомогательных источников. Я пропускаю какое-то важное чтение или проект базы данных передового опыта очень субъективен и / или зависит от приложения?

Answer 1

первичный ключ

1. должен однозначно идентифицировать строку.
2. не должно содержать данных, иначе оно изменится при изменении ваших данных (что плохо)
3. должно быть быстрым при сравнении операций (WHERE предложения / объединения)

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

Первичный ключ должен быть составлен из минимального количества полей для выполнения условий 1.-3. Для подавляющего большинства таблиц этот минимум составляет: 1 поле.

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

В таблицах отношений (отношения m: n) вы создаете составной ключ из первичных ключей связанных таблиц, следовательно, ваш составной ключ автоматически выполняет все три условия сверху.

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

Answer 2

Это довольно распространенная тема.

• Как вам ваши первичные ключи?
• Как лучше всего использовать первичные ключи в таблицах?
• Какой формат первичного ключа вы бы использовали в этой ситуации.
• Суррогатное против. Natural / Business Keys
• Должен ли я иметь специальное поле первичного ключа?

Answer 3

Всегда целые.

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

Answer 4

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

Answer 5

Что бы это ни было, сделайте это бессмысленным (суррогатный ключ). Значимые первичные ключи смертельны.

Answer 6

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