Являются ли первичные ключи устаревшими?

Question

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

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

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

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

---

EDIT

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

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

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

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

Answer 1

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

Это излишне, поскольку логически говоря все ключи могут выполнять и выполняют одну и ту же функцию,Оставляя в стороне ограничения любой конкретной СУБД, логически говоря, «первичный» ключ обладает точно такими же возможностями и функциональностью, что и любой другой ключ той же таблицы.Поэтому обозначение одного ключа как «первичного» имеет такое же важное значение, как того хочет разработчик базы данных или пользователь.Различие: произвольное (это слово используется в EFCodd) и чисто психологическое (CJDate).

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

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

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

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

Answer 2

Совершенно иная точка зрения:

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

Если вы создаете СУБД с каким-либо языком манипулирования данными, то вы имеете право называть свой язык «SQL», только если:

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

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

Answer 3

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

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

Кстати, эта тема уже задавалась и отвечала ad-nauseam уже здесь:

• В какой столбец следует кластеризовать индекс?
• Если первичные ключи всегда назначаются в качестве кластеризованного индекса
• Должен ли я создать таблицу с первичным ключом varchar или int?

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

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

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

Answer 4

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

• Поля PK автоматически НЕ ПУСТО (NULL).Поля UNIQUE НЕ имеют значения NULL, только если вы указали их как таковые (кстати, значения NULL в ограничении UNIQUE часто обрабатываются разными СУБД).
• синтаксис FOREIGN KEY по умолчанию для родительского PKЕсли вы хотите использовать родительское ограничение UNIQUE, вам нужно указать его явно.
• Кластеризация обычно основана на PK.
• PK часто отображается визуально отличным способомс помощью инструментов ER.Это может свидетельствовать о том, что (психологически) мы считаем один ключ более «важным», чем другие.

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

Answer 5

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

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

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

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

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

Из документов MSDN по SQL Ограничения FOREIGN KEY

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

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

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

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

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

Answer 6

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