В чем разница между Первичным ключом и уникальным ключевым ограничением?

Ответ 1

Оба используются для обозначения ключей кандидата для таблицы.

У вас может быть только один первичный ключ для таблицы, поэтому просто нужно выбрать его, если у вас несколько кандидатов.

Либо можно использовать в ограничениях внешнего ключа. В SQL Server столбцы первичного ключа не могут быть обнуляемыми. Столбцы, используемые в ограничениях Unique Key, могут быть.

По умолчанию в SQL Server Первичный ключ станет кластеризованным индексом, если он создан в куче, но отнюдь не обязательно, чтобы PK и кластеризованный индекс были одинаковыми.

Ответ 2

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

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

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

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

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

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

• Скорость поиска. Ключевая эффективность может быть важной, поскольку они используются во многих предложениях WHERE и (чаще) во многих JOIN s. В частности, JOINS, скорость поиска может быть жизненно важной. Влияние будет зависеть от деталей реализации, а разные базы данных будут различаться в зависимости от того, как они будут обрабатывать разные типы данных (у меня было бы несколько сомнений с точки зрения производительности при использовании большого фрагмента текста в качестве первичного ключа в Postgres, где я мог бы указать использование хэш, но я бы очень не решался это сделать в SQLServer [Edit: for "large". Я думаю о размере имени пользователя, а не о размере всего скандинавского Eddas!).

• Частота ключа - это только интересные данные. Например, с таблицей языков и таблицей комментариев на этом языке очень часто единственной причиной, по которой я хотел бы присоединиться к языковой таблице при работе с таблицей комментариев, является либо получение кода языка, либо ограничение запрос к тем, у кого есть конкретный код языка. Другая информация о языке, скорее всего, будет использоваться гораздо реже. В этом случае при присоединении к коду, вероятно, будет менее эффективно, чем присоединение к числовому идентификатору, установленному из столбца IDENTITY, имеющему код как первичный ключ, и, следовательно, как то, что хранится в столбце внешнего ключа в комментариях table - полностью устранит необходимость любого JOIN, с большим коэффициентом полезного действия. Чаще всего, хотя я хочу получить больше информации из соответствующих таблиц, поэтому сделать JOIN более эффективным является более важным.

Ответ 3

Основной ключ:

• Первичный ключ - это не что иное, как уникальная идентификация каждой строки в таблице.

• Первичный ключ не позволяет дублировать значения, а не NULL.

• Основной ключ по умолчанию - это кластеризованный индекс.

• В таблице может быть только один первичный ключ.

Уникальный ключ:

• Уникальный ключ - это не что иное, как уникальная идентификация каждой строки в таблице.

• Уникальный ключ не позволяет дублировать значения, но позволяет (не более одного) NULL.

• Уникальный ключ по умолчанию - это некластеризованный индекс.

Это полная ссылка на плод, чтобы понять Основной ключ Ключи базы данных.Имейте в виду, что в таблице имеется только один кластерный индекс. [Говоря о SQL Server 2005]. Теперь, если мы хотим добавить еще один уникальный столбец, мы будем использовать столбец Уникальный ключ, потому что В столбце "Уникальный ключ" можно добавить более одного.

Ответ 4

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

SQL, однако, имеет два разных синтаксиса для реализации ключей-кандидатов: ограничение PRIMARY KEY и ограничение UNIQUE (конечно, для столбцов, не подлежащих обнулению). На практике они достигают точно такой же цели, за исключением практически бесполезного ограничения, что PRIMARY KEY можно использовать только один раз для таблицы, тогда как ограничение UNIQUE может использоваться несколько раз.

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

Ответ 5

Краткая версия:

• С точки зрения теории базы данных ее нет. Оба являются просто ключами-кандидатами.
• На практике большинство DMBS любят иметь один "стандартный ключ", который может использоваться, например, решая, как хранить данные, и рассказать о инструментах и ​​клиентах БД, что является наилучшим способом идентификации записи.

Таким образом, различение одного уникального ключа как "первичного ключа" является просто удобством реализации (но важным).

Ответ 6

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

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

Разница между основным ключом и уникальным ограничением ключа

1. В таблице может быть только один первичный ключ, но более одного уникального ключа

2. Первичный ключ не разрешает нули, где в качестве уникального ключа допускается один null

ALTER TABLE Table_Name
ADD CONSTRAINT Constraint_Name PRIMARY KEY (Column_Name)

Alter Table Table_Name
Add Constraint Constraint_Name Unique(Column_Name)