Использовать составные клавиши? Или всегда использовать суррогатные ключи?

Ответ 1

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

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

Также проверьте некоторые из этих ссылок:

• http://www.agiledata.org/essays/keys.html
• http://rapidapplicationdevelopment.blogspot.com/2007/08/in-case-youre-new-to-series-ive.html

(конечно, другие, скорее всего, опубликуют не менее 10 ссылок PRO естественных ключей:-))

Нет никакого вреда в использовании суррогатного ключа - пойдите для этого!: -)

Марк

Ответ 2

Учитывая, что как user_id, так и group_id уже являются суррогатными ключами и, следовательно, гарантированно являются уникальными (при правильной реализации приложения), добавление третьего идентификатора является полностью избыточным.

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

Ответ 3

Всякий раз, когда я опускал суррогатный первичный ключ из таблицы соединений, я пришел, чтобы пожалеть об этом. Мне просто кажется, что когда я обойдусь, напишу код, чтобы управлять отношением, что суррогатный первичный ключ очень удобен. Я обычно следую за шаблоном Active Record и использую ASP.NET MVC, хотя ваш пробег может отличаться. В мире MVC наличие одного ключа ключа, который вы можете добавить в конец URL-адреса, очень выгодно.

Ответ 4

Я обычно рекомендую "искусственные ключи" (то, что вы называете "суррогатом" ), потому что, поскольку они практически бессмысленны вне БД, вы можете гарантировать, что им никогда не придется менять из-за внешних обстоятельств (в то время как все виды другие данные об объекте сущности могут).

Но ваша таблица user_group, типичная "две внешние ключи и все", используемая для реализации отношения много: много, - это другой случай - два внешних ключа, о которых идет речь, так же под вашим контролем, как суррогатом было бы. Суррогатный ключ для не-сущности, т.е. Строки, которая существует только для представления немного отношения, в основном просто дедвейтом - я бы рекомендовал потерять ее.

Ответ 5

Первый пример достаточно. Даже если вы должны добавлять атрибуты в конструкцию таблицы "многие ко многим" (например, 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

Ответ 6

Я бы обычно согласился с Vinko, но если вы используете ORM, например Hibernate, это может быть более счастливое отношение (между вами и Hibernate), если вы дадите все суррогатное слово.