Database 数据库设计，一个包含的属性与多个连接？困惑的

所以我要上一堂数据库设计和管理的课，从设计的角度看我有点困惑。我的例子是一个发票系统。我只是很快编出来的，这样就不会太复杂了

有客户、订单、发票和付款实体

客户 卡斯蒂德（PK）， 街道， 齐普， 城市

订单 医嘱ID（PK） 客户ID（FK） 日期 金额

发票 发票ID（PK）， 医嘱ID（FK）， 日期， 阿姆杜， AmtPaid，

付款 付款编号（PK）， 发票ID（FK）， 支付方式， 日期， 金额，

客户实体与订单有一对多关系

采购实体与发票具有一对多关系

发票实体与付款具有一对多关系

要获得查询结果以列出客户进行的所有付款，查询必须将付款与发票表、发票表与订单表以及订单表与客户表关联起来

---

这是正确的方法吗？也可以只在支付实体中放置一个custID，然后只需要一个join，但是支付实体中有不需要的信息。这只是设计问题还是性能问题

奖金问题。假设应该有一份报告，说明客户的总余额是多少。数据库中是否需要“客户余额”字段，或者这是通过连接表并将账单金额与支付金额相加而生成的计算项目

谢谢

“这是正确的方法吗？”当然，考虑到您当前的设计。但这不是唯一的办法。因此，您正在研究DB“规范化”，并了解各种规范化“形式”的优缺点。在“现实世界”中，由于管理层的决定或其他原因，事情可以在一角硬币上发生变化。我倾向于使用“复合主键”，而不是简单地使用一个字段作为主键，其他字段作为FK。我以编程方式处理我的“FK”，而不是将该责任交给DB。 我还创建和使用了许多“中间”表，有时也使用“视图”，这些表比一堆包含太多连接的代码更容易使用。（第三种正常形式的上瘾者可能会讨厌，但我的代码比烫伤的兔子运行得快）。 没有顾客，订单就没有意义；没有订单，发票就没有意义；付款很好，但没有订单和发票就没有任何意义。所以让我把这个抛到一边——有一个“摘要”类型的实体，它有客户、订单、发票和付款Id，这有什么不对

---

这是正确的方法吗

对。根据提供的信息，这似乎是合理的

也可以只在支付实体中放置一个custID，然后只需要一个join，但是支付实体中有不需要的信息。这只是设计问题还是性能问题

您所问的问题属于“正常形式”，通常称为规范化。你的目标应该是Boyce Codd范式（类似于3NF），这应该在你的教科书中描述。我将警告您，互联网上存在大量关于数据库设计问题的错误信息和误解，因此请注意您关注的答案

规范化的目标是消除冗余，从而消除“异常”，即两个逻辑等价的查询产生不一致的结果。如果相同的信息保存在两个地方，并且只在一个地方更新，那么针对这两个不同值的两个查询将产生不同的（即不一致的）结果

在您的示例中，如果有一个Payments.CustID，我应该相信它，还是应该相信从将付款加入订单中得到的？客户总余额也是如此：我是相信存储的总余额，还是我根据客户满意度计算的总余额

如果您打算“为性能去噪”，这是经常被认为是必要的，那么您将如何确保冗余值是一致的

奖金问题。假设应该有一份报告，说明客户的总余额是多少

事实上，实际上，余额是一种特殊情况。通常有必要了解各时间点的平衡情况。虽然可以根据交易从一开始就计算月账户余额，但实际上应用程序通常“在沙子上划一条线”，并记录余额以备将来参考。为了业务的需要，必须采取步骤确保历史信息不发生变化，或者，如果发生变化，则更新记录的余额以反映变化。仅从这个描述，您就可以想象，在整个系统中实施一致性的工作要比依赖DBMS来实施一致性的工作多得多。这就是为什么，在可行的情况下，最好消除所有冗余数据，让DBMS完成设计的任务

---

在你的分析中，寻找Boyce Codd范式。了解您的数据，消除冗余，并识别它们之间的关系。让DBMS强制执行引用完整性。将避免无数错误，节省时间。只有在特定情况共同表明特定的业务需求无法通过给定的正确设计在特定系统上得到满足时，是否开始了引入冗余信息并用外部控制进行补偿的繁琐且容易出错的工作。

如果有您建议的“摘要”类型的实体，是否会有大量重复信息？摘要实体只会要求添加其他信息，例如总额、地址、付款信息、，等等，等等，等等。这是一个很有吸引力的麻烦，它会导致数据重复/不一致。如果你认为没有客户，订单就没有意义，那么你从来没有这样做过