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

То, что Вы описываете, называют суррогатный ключ . Посмотрите статья Wikipedia для длинного ответа.

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

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

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

Имейте целочисленный первичный ключ, всегда хорошая вещь от предполагаемой производительности. Все Ваши отношения будут намного более эффективными с целочисленным первичным ключом. Например, СОЕДИНЕНИЯ будут намного быстрее ( SQL  Сервер ).

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

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

Если Вы живете в утонченных кругах теоретических математиков (как C. Дата делает в the-land-where-there-are-no-nulls, потому что все значения данных известны и корректны), затем первичные ключи могут быть созданы из компонентов данных, которые определяют идеализированный платонический объект, к которому Вы обращаетесь (т.е. name+birthday+place имен birth+parent), но в грязном реальном мире "синтетические ключи", которые могут определить, что Ваши реальные объекты в контексте Вашей базы данных являются намного более практическим способом сделать вещи. (И nullable поля могут быть очень полезны для. Возьмите это, людей реляционной теории дизайна!)

Да - и как показывает опыт, всегда, для каждой таблицы.

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

Это - основная хорошая практика для схем дб.

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

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

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

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

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

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

Вы также часто освобождаете способность сделать основанные на наборе операции, когда у Вас есть идентификаторы автопостепенного увеличения на всех Ваших таблицах. Вместо вставки 1 000 строк в родительскую таблицу, затем вставляя 5 000 строк в дочернюю таблицу, теперь необходимо вставить родительские строки по одному в курсор или некоторый другой цикл только для получения сгенерированных идентификаторов так, чтобы можно было присвоить их связанным детям. Я видел, что 30-секундный процесс превратился в 20-минутный процесс, потому что кто-то настоял на том, чтобы использовать идентификаторы автопостепенного увеличения на всех таблицах в базе данных.

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

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

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

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

одно место, где естественные ключи действительно работают, находится на кодовой таблице, например, таблица, отображающая состояние, оценивают его описанию. Существует мало смысла дать "Активный" первичный ключ 1, "Задержка" первичный ключ 2, и т.д. Когда столь же легко дать "Активный" первичный ключ "ACT"; "Отложенный", "DLY"; "В ожидании", "HLD" и так далее.

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