Составные первичные ключи и влияние на использование естественных / суррогатных ключей

Question

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

Предположим, вы разрабатываете схему БД дляпродукт, использующий SQL Server 2005 в качестве СУБД.Для простоты предположим, что задействованы только две сущности, которые были сопоставлены с двумя таблицами, Master и Slave.Предположим, что:

1. Мы можем иметь 0..n Ведомые записи для одной строки Мастера;
2. Набор столбцов (A, B, C, D) в Master - единственный кандидат для первичного ключа;
3. Столбец B в Master - , могут меняться с течением времени;
4. A, B, C, D - это микс столбцов varchar, decimal и bigint.

Вопрос в том, как бы вы сконструировали ключи /ограничения / ссылки для этих таблиц?Вы бы предпочли ( аргументируя свой выбор ):

1. Реализовать составной естественный ключ на Master на (A, B, C, D) исвязанный составной внешний ключ на ведомом устройстве, или
2. Введите суррогатный ключ K на ведущем устройстве, скажем, IDENTITY (1,1) столбец со связанным (один столбец)) внешний ключ на ведомом, добавление уникального ограничения на мастера (A, B, C, D) или
3. Используйте другой подход.

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

спасибо

Answer 1

Я бы выбрал вариант 2. Сохраняйте его простым.

Он ставит флажки (узкие, числовые, неизменяемые, строго монотонно растущие) для полезного кластерного индекса (который по умолчанию используется для PK в SQL).Сервер).

Однако необходимо сохранить уникальность A,B,C,D, чтобы сохранить целостность данных, как уже отмечалось.

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

Редактировать:

В случае путаницы

выбор того, какой индекс кластеризован, является отдельным от выбора ключа

Answer 2

Ваше предположение (3) имеет тенденцию предлагать вариант (2), потому что неудобно и потенциально требует много времени для каскадных обновлений первичного ключа Мастера при изменении B.

Конечно, это зависит от того, какчасто это происходит: если вы ожидаете, что это произойдет «все время», то это говорит о том, что (A, B, C, D) - плохой выбор первичного ключа;с другой стороны, если это случится редко, то (A, B, C, D) может быть хорошим выбором первичного ключа, и наличие этих столбцов в подчиненном может иметь некоторые преимущества (нет необходимости присоединяться к мастеру всехвремя, чтобы узнать эти значения столбца).

Answer 3

Либо 1,2, либо 3. Не обязательно достаточно информации, чтобы определить, нужен ли суррогат или насколько он может быть полезен.Являются ли какие-либо атрибуты составного ключа частью какого-либо ключа или ограничения в ведомой таблице?Есть ли какой-нибудь другой ключ Мастера, который можно использовать в качестве внешнего ключа?Тот факт, что значение ключа может измениться, не должен быть решающим фактором, поскольку может потребоваться изменить любое значение ключа - суррогаты не являются исключением.

существует довольно открытая дискуссия по теме

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

Answer 4

Три.

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

Это может быть целочисленный автоинкрементный ключ или глобальный уникальный идентификатор. Хранение составных ключей в любом S.Q.L. Марка сервера сложна, а иногда и чрезмерно сложна.

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

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