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

Ответы

Ответ 1

Может вызвать больше проблем для нормализации (2NF, "Обратите внимание, что когда таблица 1NF не имеет составных потенциальных ключей (ключи-кандидаты, состоящие из более одного атрибута), таблица автоматически находится в 2NF" )
Больше ненужного дублирования данных. Если ваш составной ключ состоит из 3 столбцов, вам нужно будет создать те же 3 столбца в каждой таблице, где он используется как внешний ключ.
Обычно можно избежать с помощью суррогатных ключей (прочитать об их преимуществах и недостатках)
Я могу представить хороший сценарий для составного ключа - в таблице, представляющей отношение N: N, например Students - Classes, а ключ в промежуточной таблице будет (StudentID, ClassID). Но если вам нужно хранить больше информации о каждой паре (например, истории всех марок ученика в классе), вы, вероятно, представите суррогатный ключ.

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

Во-первых, подумайте, действительно ли вам нужно продвигать ключ вообще: "само существование PRIMARY KEY в SQL, по-видимому, является исторической случайностью. По словам автора Chris Date, самые ранние воплощения SQL didn ' t имеют какие-либо ключевые ограничения, а PRIMARY KEY был позже добавлен к стандартам SQL. Дизайнеры стандарта явно взяли термин у EFCodd, который его изобрел, хотя оригинальное понятие Codd было отменено к этому времени! (Codd первоначально предложил что внешние ключи должны ссылаться только на один ключ - первичный ключ, но эта идея была забыта и проигнорирована, потому что она получила широкое признание как бессмысленное ограничение). [источник: Блог Дэвида Портаса: вниз с первичными ключами?

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

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

Ответ 6

Требуется дополнительная специфика.

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

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

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

Ответ 7

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

Ответ 8

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