database - 如何在数据库中正确维护 SSOT(Single Source Of Truth)？

Question

我是数据库的新手，我来自前端世界，我非常感谢 SSOT。毕竟，我不想看到 UI 上出现“奇怪”的东西，因为它会影响用户的行为。

现在我使用 postgres 设计自己的后端，我真的很难决定如何处理 SSOT。

假设我有 5 张 table 。 用户、订单、order_status、payment和payment_cancellation。

关系是:

• 用户 - 顺序:1-n
• order - order_status : 1-n
• order - payment : 1-n
• payment - payment_cancellation : 1-1

order_status 有 status 列，它是一个 ENUM('UNPAID', 'PAID', 'CANCELLED')。

第一个问题:order_status 表不是完全多余的吗？因为我可以完全从 order 表是否与 payment 有任何关系来导出 order_status.status 列，对吧？考虑以下场景:

• UNPAID = 没有付款的订单
• PAID = 已付款的订单
• CANCELLED = 有最后一笔付款有 payment_cancellation 的任何付款的订单

第二个问题:我不会通过 order_status 表来破坏 SSOT 吗？因为如果我没有正确处理任何关系更改，那么数据无论如何都不会有效？

第三个问题:但是，如果我没有 order_status 表，那么我将需要加入许多表才能检索最终状态。对此有什么建议吗？

非常感谢您的阅读和回答。

Answer 1

首先，认真考虑事物的命名。值 UNPAID、PAID 和 CANCELLED 似乎处理不同的事情。例如，取消订单是一回事。取消付款是完全不同的事情。仔细想想您需要了解哪些事情的状态:账单、订单、付款、发票等。

其次，在数据库世界中，我们没有像谈论规范化那样谈论单一事实来源。我已经看到过分关注 SSOT 和 DRY(不要重复自己)导致应用程序程序员走上糟糕的道路。

最后，您可能不需要 order_status 表。 (但这取决于应用程序。)规范化本身并不意味着您需要连接许多表来检索最终状态。但是在每个表中使用代理 ID 号都可以。