Краткое описание: Для каждой базовой таблицы важно иметь ключ, используя либо PRIMARY KEY, либо NOT NULL UNIQUE. Разница между ними не является реляционным соображением и не имеет значения с логической точки зрения; скорее, это всего лишь психологическое соображение.
relvar может иметь несколько ключей, но мы выбираем только один для подчеркивания и называют, что один первичный ключ. Выбор произволен, поэтому принципиальная концепция первичного не очень важна с логической точки зрения . Однако общая концепция ключа очень важна! Ключ-кандидат срока означает то же самое, что и ключ (т. Е. Добавление кандидата не имеет реального значения - оно было предложено Тедом Коддом , потому что он рассматривал каждый ключ в качестве кандидата для назначения в качестве первичного ключа ). SQL позволяет подмножество столбцов таблицы быть , объявленным как ключ для этой таблицы. Он также позволяет одному из них быть , номинированным как первичный ключ.Указание ключа, чтобы быть первичным делает для определенного удобства в связи с другими ограничениями, которые могут понадобиться
What Is a Key? by Hugh Darwen
это обычно ... выделить один ключ так как первичный ключ (и любые другие ключи для рассматриваемого рельва, как говорят, являются альтернативными ключами). Но следует ли выбрать какой-либо ключ как первичный, и если да, то какой-то являются по существу психологическими проблемами, выходящими за рамки реляционной модели как таковой. Как правило, большинство базовых relvars вероятно должны иметь первичный ключ, но, чтобы повторить это правило, , если это правило, действительно не является реляционной проблемой как таковой ... Strong рекомендация [ SQL-пользователи]. Для базовых таблиц, во всяком случае, используйте ОСНОВНЫЕ КЛЮЧИ и/или УНИКАЛЬНЫЕ спецификации, чтобы гарантировать, что каждая такая таблица имеет хотя бы один ключ.
SQL and Relational Theory: How to Write Accurate SQL Code К. Дж Дата
В стандартном SQL PRIMARY KEY
- подразумевает уникальность, но вы можете указать, что явно (с помощью
UNIQUE).
- подразумевает
NOT NULL но вы можете указать, что в явном виде при создании столбцов (но вы должны избегать аннулирует так или иначе!)
- позволяет опустить ее столбцы в
FOREIGN KEY, но вы можете указать их в явном виде.
- может быть объявлен только для одного ключа в таблице, но непонятно, почему (Кодд, который первоначально предложил концепцию, не налагал такого ограничения).
В некоторых продуктах PRIMARY KEY предполагает кластерный индекс в таблицах, но вы можете указать, что явно (вы не можете первичный ключ, чтобы быть кластерным индексом!)
Для некоторых людей PRIMARY KEY имеет чисто психологическое значение:
- они считают, что это означает, что ключ будет ссылаться на внешний ключ (это было предложено Codd, но фактически не принято стандартными SQL и поставщиками SQL).
- они считают, что это единственный ключ таблицы (но отказ от принудительного применения других ключей-кандидатов приводит к потере целостности данных).
- они думают, что это подразумевает «суррогатный» или «искусственный» ключ, не имеющий никакого значения для бизнеса (но фактически налагает нежелательное значение на предприятие, будучи подверженным пользователям).
«уникальный ключ принимает null один раз»: это не так. Кроме того, я думаю, вы должны прочитать некоторые ресурсы в Интернете, нелегко суммировать концепции в одном сообщении StackOverflow. –
Я задал этот вопрос, потому что у меня проблемы с поиском сценария в моей голове, где я бы использовал уникальный ключ. Могу ли я иметь пустой мозг, поэтому я не могу найти его! Haha –
Было бы хорошим примером имя пользователя. Вы могли бы хотеть, чтобы имена пользователей были уникальными, но с использованием сгенерированного идентификационного номера, поскольку ПК значительно облегчило бы людям изменять свое имя пользователя, так как вам не пришлось бы менять другие таблицы. Вы также можете изменить размер имени пользователя. –