Первичный ключ - это тот, который используется для идентификации рассматриваемой строки.Кроме того, он может иметь некоторый смысл (если уже есть часть «реальных» данных, которые могут служить) или это может быть просто артефакт реализации (большинство столбцов IDENTITY и эквивалентные автоматически увеличивающиеся значения в других системах баз данных)..
Уникальный ключ - это более общий случай, когда ключ не может иметь повторяющихся значений.В большинстве случаев люди не могут иметь одинаковые номера социального страхования в отношении одной и той же юрисдикции (международный случай может отличаться).Следовательно, если бы мы хранили номера социального страхования, мы бы хотели смоделировать их как уникальные, поскольку любой случай совпадения с существующим номером явно ошибочен.Имена пользователей, как правило, тоже должны быть уникальными, так что вот еще один случай.Внешние идентификаторы (идентификаторы, используемые другой системой, стандартом или протоколом), как правило, также являются уникальными, например, существует только один язык, имеющий данный код ISO 639, поэтому, если бы мы хранили коды ISO 639, мы бы смоделировали его как уникальный.
Эта уникальность также может присутствовать в нескольких столбцах.Например, в большинстве систем иерархической категоризации (например, структура папок) ни один элемент не может иметь как один и тот же родительский элемент и одно и то же имя, хотя могут быть и другие элементы с тем же родительским элементом и разными именами, а другие - с тем же именем и разнымиродители.Эта возможность нескольких столбцов также присутствует в первичных ключах.
Таблица также может иметь более одного уникального ключа.Например, у пользователя может быть как идентификационный номер, так и имя пользователя, и оба должны быть уникальными.
Следовательно, любой необнуляемый уникальный ключ может служить первичным ключом.Иногда первичные ключи, которые приходят из моделируемых врожденных данных, называются «естественными первичными ключами», потому что они являются «естественной» частью данных, а не просто артефактом реализации.Решение о том, какой использовать, зависит от нескольких вещей:
Вероятность изменения спецификации.Если мы смоделировали номер социального страхования как уникальный, а затем пришлось адаптировать его для нескольких юрисдикций, где два или более используют одинаковую систему нумерации, достаточную для коллизий, нам, скорее всего, нужно просто снять ограничение уникальности (другие изменения могут будет необходимо).Если это был наш первичный ключ, теперь нам также нужно использовать новый первичный ключ и изменить любую таблицу, которая использовала этот первичный ключ как часть отношения, и любой запрос, который к нему присоединился.
Скорость поиска.Эффективность ключа может быть важна, так как они используются во многих WHERE предложениях и (чаще) во многих JOIN s.В частности, JOINS скорость поиска может быть жизненно важной.Воздействие будет зависеть от деталей реализации, и разные базы данных различаются в зависимости от того, как они будут обрабатывать разные типы данных (у меня было бы немного сомнений с точки зрения производительности при использовании большого фрагмента текста в качестве первичного ключа в Postgres, где я мог бы указать использованиехэш присоединяется, но я бы очень не решался сделать это в SQLServer [Правка: для «большого» я думаю о размере имени пользователя, а не о размере всего скандинавского Eddas!]).
Частота ключа - единственные интересные данные. Например, с таблицей языков и таблицей комментариев на этом языке очень часто единственной причиной, по которой я хотел бы присоединиться к языковой таблице при работе с таблицей комментариев, является либо получение кода языка, либо ограничение запрос для тех, кто с определенным языковым кодом. Другая информация о языке, вероятно, будет использоваться гораздо реже. В этом случае объединение по коду, вероятно, будет менее эффективным, чем присоединение по числовому идентификатору, установленному из столбца IDENTITY, с кодом в качестве первичного ключа и, следовательно, с тем, что хранится в столбце внешнего ключа в комментариях таблица - устранит необходимость в любом СОЕДИНЕНИИ со значительным приростом эффективности. Чаще всего я хочу получить больше информации из соответствующих таблиц, поэтому более важно сделать JOIN более эффективным.