Составной первичный ключ или нет?

Question

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

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

Например:
Путь 1

create table ProxUsingDept (
    fkProx int references Prox(ProxID) NOT NULL,    
    fkDept int references Department(DeptID) NOT NULL,    
    Value int,    
    PRIMARY KEY(fkProx,fkDept)
)

Путь 2

create table ProxUsingDept (
        ID int NOT NULL IDENTITY PRIMARY KEY
        fkProx int references Prox(ProxID) NOT NULL,    
        fkDept int references Department(DeptID) NOT NULL,    
        Value int
)

Каким образомлучше?Каковы плохие стороны использования второго подхода?Есть предложения?

Answer 1

Я лично предпочитаю ваш второй подход (и использовал бы его почти 100% времени) - введите суррогатное поле ID.

Почему?

• делает жизнь намного проще для любых таблиц, ссылающихся на вашу таблицу - условия JOIN намного проще только с одним столбцом идентификатора (вместо 2, 3 или даже большего количества столбцов, которые вам нужны)все время присоединяться)

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

• значительно облегчает жизнь, поскольку база данных может обрабатывать создание уникального столбца ID (с использованием INT IDENTITY)

Однако я не знаю, как они сохраняют уникальность записей данных.

Очень просто: поместите УНИКАЛЬНЫЙ ИНДЕКС в составные столбцы, которые в противном случае вы использовали бы в качестве основного ключа!

CREATE UNIQUE INDEX UIX_WhateverNameYouWant 
   ON dbo.ProxUsingDept(fkProx, fkDept)

Теперь ваш стол гарантируетникогда не будет дублирующейся пары (fkProx, fkDept) в вашей таблице - проблема решена!

Answer 2

Вы задаете следующие вопросы:

Однако я не знаю, как они сохраняют уникальность ввода данных.

Уникальность можно сохранить, объявив отдельный составнойУНИКАЛЬНЫЙ указатель на столбцы, которые в противном случае образовали бы естественный первичный ключ.

Какой путь лучше?

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

В чем плохие стороны использования второго подхода?

Вот некоторые недостатки использования суррогатного ключа:

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

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

Answer 3

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

Допустим, у нас есть две таблицы T1 и T2.

T1 имеет столбцы C1 и C2.

T2 имеет столбцы C1, C2 и C3

C1 и C2 являются составными первичными ключами для таблицы T1 и внешними ключами для таблицы T2.

Давайте предположим, что мыиспользовал суррогатный ключ для таблицы T1 (T1_ID) и использовал его в качестве внешнего ключа в таблице T2, если значения C1 и C2 таблицы T1 изменяются, это дополнительная работа по обеспечению ограничения ссылочной интегральности в таблице T2 какмы смотрим только на суррогатный ключ из таблицы T1, значение которого не изменилось в таблице T1.Это может быть одна проблема со вторым подходом.

Answer 4

В таких случаях, как объединение таблиц M: N, наиболее целесообразно использовать составные ключи (и если изменится характер или ссылка M: N, вам все равно придется переработать эту таблицу).