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

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

РЕДАКТИРОВАТЬ:
Мне было указано, что это очень похоже на этот вопрос.

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

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


person James McMahon    schedule 10.02.2009    source источник


Ответы (6)


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

person cletus    schedule 10.02.2009
comment
Спасибо, я сделал несколько поисков, прежде чем задать этот вопрос, просмотрел теги и т. Д., Но не обнаружил ни одного из них. - person James McMahon; 10.02.2009
comment
Да, поиск SO ... не очень хорош. Вы должны знать, что искать или делать то, что я часто делаю, и ввести это в поисковые запросы google: site: stackoverflow.com. - person cletus; 11.02.2009

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

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

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

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

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

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

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

person Tomalak    schedule 10.02.2009
comment
Как создать собственный первичный ключ, если он не содержит данных? - person James McMahon; 10.02.2009
comment
@nemo: вы делаете искусственный ключ: число или GUID. Данные - это полезная нагрузка записи, я не считаю идентификатор данными. - person Tomalak; 10.02.2009
comment
Просто поправка - суррогатные ключи никогда не делаются из данных - они неизменяемы. - person D'Arcy Rittich; 10.02.2009
comment
@OrbMan: Да, я переформулировал это. Я имел в виду процесс объединения полей в ключ, но, прочитав этот абзац еще раз, увидел, что формулировка вводит в заблуждение. - person Tomalak; 10.02.2009
comment
Ой. Я смешивал суррогат и композит, извините за это. - person Tomalak; 10.02.2009
comment
@Tomalak: Значит, ключ, не содержащий данных, по определению не является родным, верно? - person James McMahon; 10.02.2009
comment
Игнорировать? наверху. Оригинальная формулировка вашего ответа смутила меня, но я понимаю, что вы имеете в виду. - person James McMahon; 10.02.2009
comment
@Nemo: собственный ключ, как вы определяете, это существующие столбцы или комбинация столбцов. Для меня это читается как данные или комбинация данных, что не рекомендуется делать. Ключ должен быть как можно более абстрактным, чтобы вы никогда не полагались / не использовали его фактическое значение. - person Tomalak; 10.02.2009
comment
То есть для чего-либо, кроме ссылки на строку и извлечения строки. - person Tomalak; 10.02.2009

Всегда цел.

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

person Assaf Lavie    schedule 10.02.2009

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

person Otávio Décio    schedule 10.02.2009
comment
Не могли бы вы объяснить это дальше? Что вы подразумеваете под значимым? - person James McMahon; 10.02.2009
comment
Я думаю, что электронную почту можно рассматривать как «значимый» первичный ключ. - person Valentin V; 10.02.2009
comment
Содержательный - типичный пример: SSN. Ключи не должны иметь никакого внутреннего делового значения. - person Otávio Décio; 10.02.2009
comment
осмысленное значение он говорит вам что-то, когда вы смотрите на него, когда вы смотрите на личность, вы не можете понять, что это означает - person SQLMenace; 10.02.2009

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

person Valentin V    schedule 10.02.2009

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

person Gary Green    schedule 10.02.2009
comment
Понятия не имею, почему вам отказали в моде, поэтому я противодействовал этому, даже если ваш ответ - повторение. - person ; 10.02.2009