database - 如何正确维护数据库中的SSOT(单一真相)？

我是新的数据库，我来自前端世界，在它我真的很感谢ssot。毕竟，我不想看到用户界面上发生“奇怪”的事情，因为它会影响用户的行为。
现在我使用postgres设计了自己的后端，我真的很难决定如何接近ssot。
假设我有五张桌子。user、order、order_status、payment和payment_cancellation。
关系是：
user-order：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_status.status有任何关系中完全导出order列，对吧？考虑以下情况：
payment=没有付款的订单
UNPAID=有任何付款的订单
PAID=有任何付款的订单，其最后一笔付款已被取消
第二个问题：
难道我不能用CANCELLED表来打破ssot吗？既然我没有正确处理任何关系更改，那么数据无论如何都是无效的？
第三个问题：
但是，如果我没有order_status表，那么我需要连接许多表，以便能够检索最终状态。有什么建议吗？
非常感谢您的阅读和回答。

最佳答案

首先，仔细考虑事物的命名。未付、已付和已取消的价值观似乎处理了不同的问题。例如，取消订单是一回事。取消付款是完全不同的事情。仔细想想你需要知道的事情：账单、订单、付款、发票等。
第二，在数据库领域，我们谈论的不是单一的真相来源，而是标准化。我已经看到，对ssot和dry的关注（不要重复你自己）导致应用程序程序员走上了可怕的糟糕道路。
最后，您可能不需要order_status表。（但这取决于应用程序）规范化本身并不意味着您需要连接许多表来检索最终状态。但是在每一个表中使用代理ID号就可以了。