Каковы недостатки использования составного / составного первичного ключа?

Каковы недостатки использования составного / составного первичного ключа?

Ответы на вопрос(8)

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

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

один простой (с одним столбцом) и один составной (с несколькими столбцами). Ваш вопрос в этом контексте выглядит следующим образом: «Какой недостаток я могу испытать, если я выберу один ключ как первичный и выберу составной ключ?»

Во-первых, подумайте, нужно ли вам вообще продвигать ключ: «само существованиеPRIMARY KEY в SQL кажется исторической случайностью. Согласно автору Крису Дейту, самые ранние воплощения SQL не имели каких-либо ключевых ограничений иPRIMARY KEY только позже был добавлен в стандарты SQL. Разработчики стандарта, очевидно, взяли термин от E.F.Codd, который изобрел его, хотя первоначальное представление Кодда к тому времени было заброшено! (Первоначально Кодд предлагал, чтобы внешние ключи ссылались только на один ключ - первичный ключ, - но эта идея была забыта и проигнорирована, поскольку она широко признана бессмысленным ограничением). "[Source:лог Дэвида Портаса: долой первичные ключи?

Во-вторых, какие критерии вы бы применили, чтобы выбрать, какой ключ в таблице должен быть «основным»? В SQL выбор ключаPRIMARY KEY является произвольным и зависит от продукта. В ACE / Jet (например, MS Access) двумя основными и часто конкурирующими факторами является то, хотите ли вы использоватьPRIMARY KEY для предпочтения кластеризации на диске или для того, чтобы столбцы, содержащие ключ, отображались жирным шрифтом на рисунке «Отношения» в пользовательском интерфейсе MS Access; Я в меньшинстве, думая, что стратегия индекса превосходит красивую картинку :) В SQL Server вы можете указать кластерный индекс независимо отPRIMARY KEY и, по-видимому, нет никаких преимуществ для конкретного продукта. Единственным оставшимся преимуществом является то, что вы можете опустить столбцыPRIMARY KEY при создании внешнего ключа в SQL DDL, поведение стандарта SQL-92 и, в любом случае, для меня не так уж важно (возможно, это еще одна вещь, которую они добавили в стандарт, потому что эта функция уже широко распространена в SQL) продукты?) Итак, дело не в том, чтобы искать недостатки, скорее, вы должны посмотреть, что Преимущество, если есть, ваш продукт SQL даетPRIMARY KEY. Другими словами, единственный недостаток при выборе неправильного ключа - то, что вы можете упустить данное преимущество.

Third, вы скорее намекаете на использование искусственного / синтетического / суррогатного ключа для реализации в вашей физической модели ключа-кандидата из вашей логической модели, потому что вы обеспокоены тем, что если вы будете использовать естественный ключ в внешних ключах и соединениях таблиц, будут штрафы за производительность ? Это совершенно другой вопрос, и он во многом зависит от вашей «религиозной» позиции по вопросу о естественных ключах в SQL.

когда вы видите его на диаграмме, он менее читабелен; когда вы используете его в соединении запросов, они менее читабельны когда вы используете его для ключа foregein, вы должны добавить проверочное ограничение для всех атрибутов, которые должны быть нулевыми или не нулевыми (если только один равен null, ключ не проверяется)usualy требуется больше памяти при использовании его в качестве внешнего ключа некоторый инструмент не управляет составным ключом

я то, что вы запутаете чертовски типичные генераторы кода ORM.

 onedaywhen19 мая 2009 г., 11:03
Я задал этот самый вопрос здесь, на SO, и популярным ответом было то, что NHibernate очень хорошо играет с составными ПК / Stackoverflow.com вопросы / 218100 / ...).
Может вызвать больше проблем для нормализации 2НФ, " Обратите внимание, что если в таблице 1NF нет составных ключей-кандидатов (ключей-кандидатов, состоящих из более чем одного атрибута), таблица автоматически получает значение 2NF ") Больше ненужного дублирования данных. Если ваш составной ключ состоит из 3 столбцов, вам необходимо создать 3 одинаковых столбца в каждой таблице, где он используется в качестве внешнего ключа. Обычно можно избежать с помощью суррогатных ключей Читайте об их преимуществах и недостатках) Я могу представить хороший сценарий для составного ключа - в таблице, представляющей отношение N: N, например «Студенты - классы», и ключ в промежуточной таблице будет (StudentID, ClassID). Но если вам нужно хранить больше информации о каждой паре (например, историю всех оценок ученика в классе), вы, вероятно, введете суррогатный ключ.
 Arthur Thomas20 сент. 2008 г., 08:59
суррогатный ключ! Я не мог вспомнить слово в данный момент, спасибо! :)

кальным ненулевым ограничением на натуральный составной ключ.

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

что это специализация дебатов по синтетическим ключам (будь то использование значимых ключей или произвольного синтетического первичного ключа). Я почти полностью остановился на синтетической ключевой стороне этой дискуссии по ряду причин. Вот некоторые из наиболее подходящих:

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

На глубокой схеме ключи могут быть достаточно широкими - я видел один раз 8 столбцов.

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

Большинство проблем с не синтетическими первичными ключами вращаются вокруг проблем, когда значения PK записей изменяются. Наиболее полезные применения несинтетических значений - это когда схема базы данных предназначена для использования, например, M.I.S. приложение, в котором составители отчетов используют таблицы напрямую. В этом случае короткие значения с фиксированными доменами, такие как коды валют или даты, могут быть разумно размещены непосредственно в таблице для удобства.

Слишком далеко, это может привести к чрезмерному усложнению вставок (каждый ключ ДОЛЖЕН существовать) и документации, а присоединенные чтения могут быть подозрительными, если они не завершены.

Иногда это может указывать на некорректную модель данных (действительно ли составной ключ ДЕЙСТВИТЕЛЬНО описывает данные?)

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

 Tom Carr20 сент. 2008 г., 08:55
Правда, но при вставке / обновлении не читается.
 012481620 сент. 2008 г., 09:00
Ну, индекс будет больше, так что да, вы будете платить больше за чтение.
 Arthur Thomas20 сент. 2008 г., 09:02
На самом деле, это напоминает мне. Некоторые составные индексы работают, только если первый ключ включен в поиск по индексу (A, B). Если вы просто используете B, тогда он должен выполнить полный поиск без индекса. Postgres похож на это и может также зависеть от типа индекса, но я не уверен. Так что это может повлиять на чтение. хе-хе
 Arthur Thomas20 сент. 2008 г., 08:43
Хорошо, я бы сказал, что затраты на производительность могут возрасти, поскольку вы должны хранить индексы для числа элементов первичного ключа, но я просто упомяну это для полноты.

Ваш ответ на вопрос