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

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

I am always voting for keys that are as narrow as possible, static (never change) and thus I usually favor a surrogate INT as a key over a compound key.

If you want to reference a compound key from another table, you'll always have to specify several conditions - which can get quite unwieldy at times!

Also check out some of those links:

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

(of course, others will likely post at least 10 links PRO natural keys :-) )

There's no harm in using a surrogate key - go for it! :-)

Marc

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

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

The first example is sufficient. Even if you were to add attributes to the many-to-many table construct (like is_main_grp, etc.), there is no real need for a surrogate in the link table, and you'll probably always want a unique constraint on user_id, group_id anyway.

Only if you were to hang another many-to-one relationship on the link relationship (like tags), THEN I would think about having a surrogate in the user_group table, and I would not do it until it was a requirement (since a surrogate is relatively easy to add):

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

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

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

Обычно я бы согласился с Винко, но если вы используете ORM, например Hibernate, отношения (между вами и Hibernate) могут быть более счастливыми, если вы дадите всему суррогатный ключ.