循环数据库关系。好，坏，例外？

Question

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

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

• 信用卡式
• 客户
• 顺序

我希望如此，

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

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

实际上，这会在三个表之间创建一个循环设计。

可能的解决方案： 任

创建循环设计，提供参考：

• cc ref to order，
• 客户参考cc
• 客户参考订单

或

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

基本上两种模型都采用相同的设计，但翻译方式不同，我现在最喜欢后一种选择，因为它似乎不那么循环，而且更加集中。 （如果这甚至有意义的话）

我的问题是，

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

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

- 更新/编辑 -

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

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

Answer 1

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

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

Answer 2

嗯？

客户有几张信用卡，但只有一张信用卡。订单只有一张指定的卡。当顾客购买东西时，首先尝试他的默认卡，否则，他可能会更换他的主卡？

我在这里看不到循环引用;当用户的信用卡发生变化时，他的订单保持不变。您的表格最终会显示为：

• 客户：id，当前卡
• 信用卡：id，number，customer_id
• 订单：id，Card_id，Customer_id

编辑：哎呀，忘了一个字段，谢谢。

Answer 3

我认为问题在于订单的建模。而不是一个订单有一张信用卡，订单应该能够与多张信用卡相关联，其中只有一张信用卡在任何时候都有效。从本质上讲，订单和信用是多对多的。为了在DB中对此进行建模，您需要引入一个关联表，比如说PaymentHistory。现在，当订单需要新的信用卡时，您只需创建一张新的信用卡，并将其与订单关联，并将关联的PaymentHistory标记为有效。

Answer 4

无论您的数据是否具有循环关系，如果您“忘记”声明其中一个以便您的表具有批量加载顺序，那么您会更开心。

当你最不期望它时会派上用场。

Answer 5

这是一岁，但有一些值得做的事。

注意：对于在线NON-ACCOUNT流程：客户可以更好地定义为买方，也可能还有其他类型的客户 - 受益人/收件人。您可以为其他人购买/购买机票和鲜花等，因此这两个角色需要明确分开，因为它们涉及不同的业务流程（一个用于支付，另一个用于发送货物）。

如果是非帐户流程，则您不应保留信用卡详细信息。这是一种安全风险 - 而且您通过保留此信息使买方面临风险。信用卡实时处理，然后丢弃信息。

帐户客户：唯一的例外是当有人开设帐户并提供其信用卡信息以供后续购买时使用。在这种情况下，信用卡信息的更改将在交易之外进行 - 作为账户管理流程的一部分。

重点是确保在开始建模和编码之前完全理解业务流程。