代码之家 › 专栏 › 技术社区 › lsl

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

relational-model entity-relationship rdbms sql

2

lsl · 技术社区 · 17 年前

我已经推迟了一段时间开发我的应用程序的这一部分,纯粹是因为我想以循环的方式来做这个,但是从我记得我的老师在学校里告诉我的事情中,我感觉这是一个坏主意。

我设计了一个订单系统,忽略了不属于这个示例的所有内容:

信用卡
顾客
秩序

我想要这样,

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

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

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

可能的解决方案: 要么

创建圆形设计,提供参考:

CC参考订单,
客户参考CC
客户参考订单

或

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

从本质上说,这两个模型设计相同,但翻译不同,我最喜欢后一个选项,因为它看起来不太圆,更中心。(如果这有道理的话)

我的问题是,

如果每种方法都有优缺点呢?
循环关系/依赖关系的陷阱是什么?
这是规则的有效例外吗?
我有什么理由选择前者而不是后者?

谢谢,如果您有什么需要澄清/解释的,请告诉我。

--更新/编辑——

我注意到我所说的要求中有一个错误。基本上是在试图简化事情的时候丢了球。还有另一个付款表,添加了另一层。在这种情况下,订单可以有多种支付方式,也可以使用不同的信用卡。(如果你真的想知道,即使是其他形式的付款)。

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

5 回复 | 直到 16 年前

1

7

dkretz 17 年前

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

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

2

1

Journeyman Programmer 17 年前

我认为问题在于订单的建模。与一个订单拥有一张信用卡不同,一个订单应该能够与多个信用卡关联,而在任何时候只有一个信用卡处于活动状态。从本质上讲,订单和信用是多对多的。为了在数据库中建模,需要引入一个关联表,比如paymenthistory。现在,当订单需要新的信用卡时,您可以简单地创建一个新的信用卡,并将其与订单关联,并将关联付款历史记录标记为活动。

3

1

Tordek 17 年前

隐马尔可夫模型?

一个客户有几张信用卡,但只有一张是当前的。订单有一张指定的卡。当一个顾客买东西时,他的默认卡会先被试用,否则,他可以换主卡吗?

我在这里看不到循环引用;当用户的信用卡更改时,他的订单保持不变。你的桌子最终会变成:

客户:身份证、活期卡
信用卡:ID、号码、客户ID
订单:ID、卡ID、客户ID

编辑: 哎呀,忘了一块地,谢谢。

4

0

Joshua 17 年前

无论数据具有循环关系的原因是什么,如果您“忘记”声明其中的一个关系以便表具有大容量加载顺序,您都会更高兴。

这在你最不经意的时候就派上用场了。

5

0

Clive Fletcher 16 年前

这是一年前的事,但有一些要点值得一提。

注意:对于在线非账户流程:客户最好定义为买方,也可能有另一种类型的客户-受益人/接收人。您可以为其他人购买机票和鲜花等,因此这两个角色需要明确区分,因为它们涉及不同的业务流程(一个用于支付,另一个用于发送货物)。

如果这是一个非账户流程,那么您不应该保留信用卡的详细信息。这是一种安全风险——你保留这些信息会让买家面临风险。信用卡是实时处理的,然后信息应该被丢弃。

账户客户:唯一的例外情况是,有人开立了一个账户,并提供了他们的信用卡信息,供以后购买时使用。在这种情况下,信用卡信息的更改将在交易之外发生,这是账户管理过程的一部分。

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