Дубликат: Множество ко многим связям - Дизайн таблицы пересечений
Если у меня есть эти таблицы (* = первичный ключ):
user
id*
name
group
id*
name
Это лучше?
user_group
user_id*
group_id*
Или это лучше?
user_group
id*
user_id
group_id
Я всегда голосую за ключи, которые настолько узки, насколько это возможно, статические (никогда не меняются), и поэтому я обычно предпочитаю суррогатный INT как ключ над сложным ключом.
Если вы хотите ссылаться на составной ключ из другой таблицы, вам всегда нужно будет указать несколько условий, которые иногда могут быть довольно громоздкими!
Также проверьте некоторые из этих ссылок:
(конечно, другие, скорее всего, опубликуют не менее 10 ссылок PRO естественных ключей:-))
Нет никакого вреда в использовании суррогатного ключа - пойдите для этого!: -)
Марк
Учитывая, что как user_id, так и group_id уже являются суррогатными ключами и, следовательно, гарантированно являются уникальными (при правильной реализации приложения), добавление третьего идентификатора является полностью избыточным.
Если вы не используете какой-либо ORM, который (к сожалению) обычно усложняет обработку составных клавиш. В этом случае вы должны оценить стоимость избыточности и простоту разработки с выбранным ORM.
Всякий раз, когда я опускал суррогатный первичный ключ из таблицы соединений, я пришел, чтобы пожалеть об этом. Мне просто кажется, что когда я обойдусь, напишу код, чтобы управлять отношением, что суррогатный первичный ключ очень удобен. Я обычно следую за шаблоном Active Record и использую ASP.NET MVC, хотя ваш пробег может отличаться. В мире MVC наличие одного ключа ключа, который вы можете добавить в конец URL-адреса, очень выгодно.
Я обычно рекомендую "искусственные ключи" (то, что вы называете "суррогатом" ), потому что, поскольку они практически бессмысленны вне БД, вы можете гарантировать, что им никогда не придется менять из-за внешних обстоятельств (в то время как все виды другие данные об объекте сущности могут).
Но ваша таблица user_group, типичная "две внешние ключи и все", используемая для реализации отношения много: много, - это другой случай - два внешних ключа, о которых идет речь, так же под вашим контролем, как суррогатом было бы. Суррогатный ключ для не-сущности, т.е. Строки, которая существует только для представления немного отношения, в основном просто дедвейтом - я бы рекомендовал потерять ее.
Первый пример достаточно. Даже если вы должны добавлять атрибуты в конструкцию таблицы "многие ко многим" (например, is_main_grp и т.д.), Нет реальной потребности в суррогате в таблице ссылок, и вы, вероятно, всегда захотите установить уникальное ограничение на user_id, group_id в любом случае.
Только если вы должны были повесить еще несколько отношений "один-два" на связь (например, теги), THEN, я подумал бы о наличии суррогата в user_group, и я бы не сделал этого, пока это не было требованием (поскольку суррогат относительно легко добавить):
user
id*
name
group
id*
name
user_group
id*
user_id
group_id
is_main_grp
user_group_tags
user_group_id*
tag_id*
tags
id*
tag_txt
Я бы обычно согласился с Vinko, но если вы используете ORM, например Hibernate, это может быть более счастливое отношение (между вами и Hibernate), если вы дадите все суррогатное слово.