我是数据库新手，我来自前端世界，在其中我非常感谢SSOT。毕竟，我不想在UI上看到“怪异”的东西，因为它会影响用户的行为。
现在，我使用postgres设计自己的后端，在决定如何处理SSOT方面确实遇到了困难。
假设我有5张桌子。 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的{{1}}列是status。
第一个问题：
ENUM('UNPAID', 'PAID', 'CANCELLED')表不是完全多余的吗？因为我可以完全根据order_status表是否与order_status.status有关系来导出order列，对吗？请考虑以下情形：
payment =未付款的订单UNPAID =有任何付款的订单PAID =具有任何付款的订单，其最后一次付款具有payment_cancellation 第二个问题：
我不会通过拥有CANCELLED表来破坏 SSOT 吗？由于如果我没有正确处理任何关系更改，那么数据将仍然无效吗？
第三个问题：
但是，如果我没有order_status表，那么我将需要加入许多表才能检索最终状态。有什么建议吗？
非常感谢您阅读和回答。
答案 0 :(得分：1)
首先，认真考虑事物的命名。值UNPAID，PAID和CANCELED似乎处理不同的事情。例如，取消订单是一回事。取消付款是完全不同的事情。仔细考虑一下您需要了解状态的各种事物：账单，订单，付款，发票等。
第二，在数据库世界中，我们谈论的只是单一事实来源。我发现对SSOT和DRY的关注（不要重复自己）使应用程序程序员走上了可怕的糟糕道路。
最后，您可能不需要order_status表。 （但这取决于应用程序。）规范化本身并不意味着您需要连接许多表来检索最终状态。但是在每个表中都使用代理ID号。