Эффективность составного первичного ключа как внешнего ключа

12

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

Мой вопрос в том, какой подход более эффективен для скорости поиска:

1) Создать ли новую таблицу, включающую все 4 столбца, и ссылаться на них во внешнем ключе.

или

2) Создать ли новый столбец идентификаторов в таблице первичного ключа и использовать его в качестве внешнего ключа в новой таблице.

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

— aaroncatlin
источник

1

Лично я почти всегда использовал бы суррогатный ключ (например, an INT IDENTITY) в таком случае - сделать ссылки на эту таблицу и присоединиться к ней просто так намного проще. Чтобы избежать дублирования, наложите уникальное ограничение на эти четыре столбца. Кроме того: узкие первичные ключи намного лучше по соображениям производительности (если они используются в качестве ключа кластеризации)

— marc_s

11

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

Как вы указали, у вас будут гораздо более простые отношения с ФК.
Маленький ПК делает для маленьких (и быстрых) индексов. Ваше общее табличное пространство, вероятно, будет уменьшено при добавлении такого столбца.
Если бизнес-правила когда-либо изменятся, вам не придется менять порядок столов.

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

— Джон на все руки
источник

5

Как это часто бывает в мире SQL, ответ таков: «Это зависит».

Посмотрите на этот вопрос для некоторых указателей: обеспечивают ли естественные ключи более высокую или более низкую производительность в SQL Server, чем суррогатные целочисленные ключи?

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

Если вы введете этот столбец IDENTITY, я бы даже сделал его Первичным ключом и заменил бы «естественные» столбцы на UNIQUE CONSTRAINT.

— Себастьян Майн
источник