循环数据库关系.好,坏,例外?

Lou*_*uis 2 sql rdbms entity-relationship relational-model

我一直推迟开发应用程序的这一部分纯粹是因为我想以循环的方式做到这一点,但从我记得我的讲师告诉我回到学校的时候,感觉这是一个坏主意.

我有一个订单系统的设计,忽略了与我留下的这个例子无关的一切:

  • 信用卡
  • 顾客
  • 订购

我想这样,

  • 客户可以使用信用卡(0-n)
  • 客户有订单(1-n)
  • 订单有一个客户(1-1)
  • 订单有一张信用卡(1-1)
  • 信用卡可以有一个客户(1-1)(唯一ID,因此我们可以忽略cc号的唯一性,丈夫/妻子可以共享cc实例等)

基本上最后一部分是问题出现的地方,有时信用卡被拒绝,他们希望使用不同的信用卡,这需要更新他们的"当前"卡,但这只能更改用于该订单的当前卡,而不是客户可能在磁盘上的其他订单.

实际上,这在三个表之间创建了圆形设计.

可能的解决方案:要么

创建圆形设计,给出参考:

  • cc参考订购,
  • 客户参考cc
  • 客户参考订购

要么

  • 客户参考cc
  • 客户参考订购
  • 创建引用所有三个表ID的新表,并在订单上放置唯一,以便任何时候只有一个cc可以是该订单的当前

基本上两者都是相同的设计模型,但翻译方式不同,我在这个时间点最喜欢后一种选择,因为它看起来不那么循环,而且更加集中.(如果这甚至有意义)

我的问题是,

  • 如果有的话各有利弊怎么办?
  • 循环关系/依赖的缺陷是什么?
  • 这是规则的有效例外吗?
  • 有什么理由我应该选择前者而不是后者?

谢谢,如果有任何需要澄清/解释,请告诉我.

--update/Edit--

我注意到我说的要求有误.当试图简化SO的事情时,基本上丢球.付款还有另一张表,增加了另一层.捕获,订单可以多次付款,可以使用不同的信用卡.(如果你真的想知道其他形式的付款).

在此陈述这一点是因为我认为潜在的问题仍然是相同的,这只会增加另一层复杂性.

dkr*_*etz 7

客户可以拥有0个或更多信用卡,但关联是动态的 - 它可以来来去去.正如您所指出的,信用卡可以与多个客户相关联.所以这最终成为一个n:m表,可能有一个标记列为"活动".

订单与0或1个信用卡具有静态关系,并且在销售完成后,无论cc与客户之间的关系如何发生,您都不会弄乱cc值.订单表应独立存储销售时cc的所有相关信息.没有理由将销售与任何其他表中的任何其他信用卡列相关联(这可能会改变 - 但不会影响销售).