Композитный первичный ключ или нет?
Вот что меня смущает. У меня часто есть составные первичные ключи в таблицах базы данных. Плохая сторона этого подхода заключается в том, что у меня есть довольно много работы, когда я удаляю или редактирую записи. Тем не менее, я считаю, что этот подход находится в духе проектирования базы данных.
С другой стороны, есть мои друзья, которые никогда не используют составные клавиши, а скорее вводят другой столбец "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. Это может быть одна проблема со вторым подходом.