Композитный первичный ключ или нет?

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

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

Например:
Путь 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
)

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

Ответ 1

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

Почему?

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

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

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

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

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

Ответ 2

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

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

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

Какой способ лучше?

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

Каковы плохие стороны использования Второй подход?

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

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

Ответ 3

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

Ответ 4

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

Скажем, мы имеем две таблицы T1 и T2.

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

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

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

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