sql - 循环数据库关系。好，坏，异常(exception)？

Question

一段时间以来，我一直在推迟开发我的应用程序的这一部分，纯粹是因为我想以一种循环的方式来做这件事，但从我记得我的讲师告诉我的事情中，我觉得这是一个坏主意。

我有一个订单系统的设计，忽略了与我剩下的这个示例无关的所有内容:

• 信用卡
• 客户
• 订单

我想要这样，

• 客户可以有信用卡(0-n)
• 客户有订单(1-n)
• 订单有一个客户(1-1)
• 订单有一张信用卡(1-1)
• 信用卡可以有一个客户(1-1)(唯一的 ID，所以我们可以忽略抄送号码的唯一性，丈夫/妻子可以共享抄送实例等)

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

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

可能的解决方案: 要么

创建圆形设计，给出引用:

• 抄送订单，
• 客户抄送
• 客户订单引用

或

• 客户抄送
• 客户订单引用
• 创建引用所有三个表 ID 的新表并在订单上设置唯一性，以便任何时候该订单可能只有一个 cc 是当前的

本质上，两者都采用相同的设计模型，但翻译方式不同，我目前最喜欢后一种选择，因为它看起来不那么循环，而且更中心化。 (如果这甚至有意义的话)

我的问题是，

• 如果有的话，各自的优缺点是什么？
• 循环关系/依赖的陷阱是什么？
• 这是规则的有效异常(exception)吗？
• 我有什么理由应该选择前者而不是后者吗？

谢谢，如果您有任何需要澄清/解释的地方，请告诉我。

--更新/编辑--

我注意到我陈述的要求中有错误。在尝试为 SO 简化事情时基本上丢球了。那里还有另一个用于支付的表格，它增加了另一层。要注意的是，订单可以多次付款，并且可以使用不同的信用卡。 (如果您真的想了解其他付款方式)。

在这里说明这一点是因为我认为潜在的问题仍然是相同的，这只会增加另一层复杂性。

Answer 1

客户可以关联 0 张或多张信用卡，但关联是动态的 - 它可以来来去去。正如您所指出的，信用卡可以与多个客户相关联。所以这最终成为一个 n:m 表，可能带有一个用于“事件”的标志列。

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