【问题标题】:Database design - children of join tables key choice数据库设计 - 连接表的子项关键选择
【发布时间】:2016-03-24 15:24:56
【问题描述】:

我搜索了以下问题的答案,但得到的答案主要与是否使用代理项有关,而不是关于是否对连接表的子项使用复合键。

我有一张桌子attendees 和一张桌子events

连接表为event_attendees,包含两个外键attendee_idevent_id,还有一个代理主键id

现在假设参加活动的参与者可以拥有schedule_items

我通常会简单地使用表event_attendee_schedule_items 中的event_attendee_idschedule_item_id 列。

如果有的话,使用以下复合外键设置有什么缺点?

attendee_idevent_idschedule_item_id(复合键而不是指向event_attendees 表的直接链接)?

【问题讨论】:

  • 第二种解决方案,使用复合键,对我来说听起来更合乎逻辑。由于您一次在一个地方有一个人...您将三个表链接在一起...

标签: sql foreign-key-relationship surrogate-key


【解决方案1】:

如果出现以下情况,我会推荐第一种方法:

  • event_attendees 仍然是必需的。因为如果您有两个连接表event_attendeesevent_attendee_schedule_items(如果您使用第二种方法,这基本上是您得到的),您可能会输入不一致的数据。即使您可以保证这两个表是同步的(例如通过正在写入数据的外部程序),我也不会这样做。

  • 您对其他相同样式的扩展有想法,例如表格event_attendee_invoice_parts(将链接到发票数据),您可以将常用数据放入event_attendees

  • event_attendees 有自己的属性,如entry_badge_id,将在event_attendee_schedule_items 的上下文中使用。对于这个查询,无论如何你都必须加入event_attendees

最后一个原因给了我们一个额外的提示:这取决于表中的数据量和您所做的查询!在某些情况下,您的性​​能将受益于复合键(和复合 索引),在其他情况下不是。有关详细讨论,请参阅this question

【讨论】:

  • 这就是我最终要做的。我以前用过你描述的最好的模式,效果很好。最大的不同,也是我没有想到的一个好点是在那个 event_attendees 表上存储公共数据的想法。感谢您的回复。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-07-24
  • 2011-10-24
  • 1970-01-01
相关资源
最近更新 更多