Первичные ключи passé?

Какую уникальную функциональность предоставляют первичные ключи?

В то время как я назвал вопрос языком, крепко посаженным в щеку, мой вопрос серьезен. Прежде чем начнется какое-либо пламя, я не говорю о создании базы данных без ограничений или ссылочной целостности. Однако, насколько я могу судить, SQL Server может покончить с ключевым словом primary key.

Уникальные индексы покрывают, ну, уникальность
Недействительность столбца, основанная на столбцах, охватывает требование нечетности для PKs
PK не нужно кластеризовать, чтобы он не
Внешние ключи могут и часто выполняются с уникальными индексами, а не с ПК
Даже MSDN заявляет, что создается уникальный индекс для обеспечения уникальности ПК

Я согласен с тем, что логически Первичный ключ создает немного намерения относительно модели данных, но так ли это? [сарказм] О, и мы получим эту маленькую иконку с символами SSMS при проектировании стола! [/Сарказм]

ИЗМЕНИТЬ

Из комментариев видно, что я не задавал этот вопрос так четко, как я думал. Я согласен с тем, что первичные ключи важны с логической точки зрения.

Я не спрашиваю:

должен ли я выбрать int или varchar для моего ПК
нужно ли кластеризовать ПК, или как определить, что должно быть кластеризованным.
как однозначно идентифицировать строки

Мое намерение состояло в том, чтобы спросить: "Какие функции предоставляет PK, который не может быть разумно реализован с использованием других функций?" Я не предлагаю сходить с ума здесь - например, с помощью триггера для обеспечения уникальности вместо уникальных ограничений/индексов. Разумное является ключевым словом здесь - и использование уникального индекса/ограничения кажется очень похожим на определение PK.

Ответ 1

Совершенно другая перспектива:

SQL - это язык, который определяется стандартом ISO. Этот стандарт имеет "обязательные" функции и "необязательные соответствия".

Если вы создаете СУБД с некоторым языком обработки данных, тогда вы имеете право называть ваш язык "SQL" только в том случае, если:

(a) вы внедрили ВСЕ синтаксис, предписанный стандартом ( "обязательные" функции), и (b) все языковые функции, которые вы внедрили (все обязательные как минимум, но также и "необязательные", которые вы "выбрали" для), выставляете именно то поведение, которое определено/описано в стандарте.

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

Ответ 2

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

Это лишнее, потому что логически говоря, все клавиши могут и выполняют одну и ту же функцию. Оставляя в стороне ограничения какой-либо конкретной СУБД, логически говоря, "первичный" ключ обладает теми же функциями и функциональностью, что и любой другой ключ той же таблицы. Поэтому обозначение одного ключа как "первичного" так важно, как разработчик базы данных или пользователь хочет, чтобы это было. Различие произвольно (слово, используемое E.F.Codd) и чисто психологическое (C.J.Date).

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

Концепция "первичного ключа" бесполезна по крайней мере по двум причинам. Во-первых, поставщики программного обеспечения для инструментов разработки баз данных, СУБД и средств моделирования, к сожалению, приложили всевозможные программные функции к ключам, обозначенным как "первичный ключ". Это фактически работает против первоначальной концепции. Нам больше не нужно выбирать один ключ для таблицы, который имеет логическое значение для дизайнера или пользователя. Мы поощряемся или даже вынуждены выбирать "первичные" ключи для поддержки той или иной функции в программном обеспечении X, Y или Z независимо от других соображений. Это очень печально, потому что это представляет собой ограничение и отсутствие гибкости в программном обеспечении. Мы должны быть свободны выбирать подходящий ключ для каждой цели и не ограничиваться одним ключом для каждой таблицы для каждой цели.

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

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

Ответ 3

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

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

Кстати, эта тема была задана и ответила ad-tauseam уже здесь:

Чтобы немного рассказать о различиях между ограничениями PK и UNIQUE: даже если есть несколько свойств, которые имеют уникальные ограничения и поэтому могут служить PK, только один из них будет правильным выбором, они не равны. Который полностью зависит от модели данных, к бизнесу, означающему сущность и то, что представляет каждое свойство. ПК не важна для СУБД, СУБД действительно заботится о кластеризованном ключе и уникальности намного больше, чем о ПК. ПК для вас, разработчика и вашего инструментария. Вы не хотите, чтобы каждый разработчик указывал на базу данных с помощью инструмента ORM для выбора другого уникального ключа в качестве идентификатора сущности, а затем каждый из них записывал код, который хранит другое свойство как идентификатор. Вы хотите, чтобы все выбрали тот же самый, первичный ключ, потому что у него есть другие атрибуты, кроме того, что они уникальны. Ярким примером является Stability, значение PK является стабильным на протяжении всего срока службы объекта (если нет, то PK был выбран правильно).

какие функции предоставляет ПК, которые не могут быть разумно реализованы используя другие функции?

Маленький значок SSMS. Серьезно, в конечном счете, это то, что сводится к: ПК передает дополнительную информацию, какая из возможных ключей на самом деле та, которая идентифицирует сущности в таблице. "Зависимость от траектории" играет значительную роль в сегодняшней позиции ПК, соглашается, но если бы не та, что какая-то другая конструкция поднимется, чтобы выполнить именно эту роль о намерении о логической модели.

Ответ 4

Теоретически все ключи эквивалентны, но мы выбираем один из них как "первичный" по психологическим и практическим причинам. Некоторые соображения:

Поля PK автоматически NOT NULL. Поля UNIQUE не являются NULL, только если вы укажете их как таковые (BTW, NULL в ограничении UNIQUE часто обрабатываются по-разному разными СУБД).
Синтаксис FOREIGN KEY по умолчанию соответствует родительскому PK. Если вы хотите использовать ограничение родительского UNIQUE, вам нужно явно указать его.
Clustering обычно основывается на PK.
PK часто отображается визуально различным способом с помощью инструментов ER. Это может документировать, что (психологически) мы считаем один ключ более "важным", чем другие.

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

Ответ 5

Вы указываете, что

логически Первичный ключ coveys немного намерения

и Аарон Бетранд указывает в комментариях

У вас может быть несколько уникальных ограничений или уникальных индексов, но только один должен быть таким, каким вы обычно ожидаете идентифицировать строку

Я предполагаю, что Аарон использовал такие слова, как должно и, как правило, потому, что он знает, что даже внешние ограничения для ключей требуют только уникального ограничения

Из документов MSDN по SQL FOREIGN KEY Constraints

Ограничение FOREIGN KEY не должно связываться только с ограничением PRIMARY KEY в другой таблице; его также можно определить для ссылки на столбцы ограничения UNIQUE в другой таблице

Кроме того, C.J. Date также отмечается в разделе Введение в системы баз данных

Если набор ключей-кандидатов фактически включает более одного член, тогда выбор которого должен быть первичным, по существу произвольный *

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

* C.J. Дата объясняет здесь, что выбор Первичного ключа не является полностью произвольным. Например, изменчивый первичный ключ будет плохой идеей.

Ответ 6

Первичные ключи автоматически индексируются во всех системах БД. (По крайней мере, в тех, которые я знаю до сих пор.)