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

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

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