一段时间以来,我一直推迟开发我的应用程序的这一部分,纯粹是因为我想以一种循环的方式来做这件事,但是从我记得我的讲师在学校告诉我的事情中感觉这是一个坏主意。
我有一个订单系统的设计,忽略了与这个示例无关的所有内容:
- 信用卡
- 顾客
- 命令
我想要这样,
- 客户可以有信用卡(0-n)
- 客户有订单(1-n)
- 订单有一位客户(1-1)
- 订单有一张信用卡(1-1)
- 信用卡可以有一个客户(1-1)(唯一的 id,所以我们可以忽略 cc 号码的唯一性,丈夫/妻子可以共享 cc 实例等)
基本上最后一部分是问题出现的地方,有时信用卡被拒绝并且他们希望使用不同的信用卡,这需要更新他们的“当前”卡,但这只能更改用于该订单的当前卡,而不是客户可能在磁盘上的其他订单。
这有效地在三个表之间创建了一个圆形设计。
可能的解决方案:要么
创建圆形设计,提供参考:
- cc 参考订购,
- 客户参考抄送
- 客户参考订购
或者
- 客户参考抄送
- 客户参考订购
- 创建引用所有三个表 id 的新表并在订单上放置唯一的,以便在任何时候只有一个 cc 可能是该订单的最新
本质上,两者都对相同的设计进行建模,但翻译方式不同,此时我最喜欢后一种选择,因为它看起来不那么圆,更中心化。(如果这有道理的话)
我的问题是,
- 如果有的话,每个人的优点和缺点是什么?
- 循环关系/依赖的陷阱是什么?
- 这是该规则的有效例外吗?
- 有什么理由我应该选择前者而不是后者?
谢谢,让我知道您是否需要澄清/解释任何事情。
--更新/编辑--
我注意到我所说的要求中有一个错误。在尝试为 SO 简化事情时基本上丢球了。Payments 那里还有另一个表,它增加了另一个层。问题是,订单可以进行多次付款,并且可以使用不同的信用卡。(如果您真的想知道其他付款方式)。
在这里说明这一点是因为我认为根本问题仍然是相同的,而这只确实增加了另一层复杂性。