我正在设计一个数据库，我需要在其中存储客户的已付款订单和未付款订单。这两类订单都有< strong>与其他表具有相同的属性和关系。
我想出了两个设计:
<强>1。两类订单的单独表格: 
优点:这种设计帮助我快速区分购物车中的订单和已支付的订单。每当客户重新访问我的网站时，我只需要查找该特定客户的 UnpaidOrder 表，我的购物车就准备好了。
缺点:每当为 UnpaidOrder 表中的订单付款时，我需要将相应的行(UnpaidOrder 和与其链接的其他表)移动到 PaidOrder 表及其相应的表。此外，此设计将需要 2 倍数量的表:例如。 UnpaidOrderDeliveryAddress、UnpaidOrderCreditCard、...用于与 UnpaidOrder 和 PaidOrderDeliveryAddress、PaidOrderCreditCard、...与 PaidOrder 的关系。
<强>2。两个类别和一个额外状态属性的公用表: 
优点:我不需要在支付未付款订单时移动多行。同时，对应关系的表数减半。
缺点:我为每一行存储了一个额外的 Status 属性。每当客户重新访问我的网站时，我都需要查找订单表，并且我需要检查该特定客户每一行的状态属性(付费/未付费)。因此，购物车将需要更长的时间来加载。
我的问题是:
- 考虑到用户众多且应用程序繁重，哪种设计在性能方面更好？
- 有什么好的替代方案可以满足我的要求吗？
最佳答案
另一种意见....
不需要额外的规范化表(UnpaidOrderDeliveryAddress、UnpaidOrderCreditCard，...用于与 UnpaidOrder 和 PaidOrderDeliveryAddress 的关系，PaidOrderCreditCard，...用于 PaidOrder)。如果你认为 FOREIGN KEYs 需要这样，我会反对在这种情况下使用 FOREIGN KEYs。简单的索引就足够了。
由于您最终会拥有比“未付费”条目更多的“付费”条目，而付费条目本质上是您很少需要接触的“历史”，因此我倾向于 2 个表格。
我可能不会使用触发器——我宁愿在我有更多控制权的应用程序代码中使用它。
您是否期望每秒执行超过 100 条 SQL 语句？如果不是，我不会称之为“重”。
一定要小心地用 BEGIN..COMMIT 包围适当的语句组。此外，对导致 UPDATE 的 SELECT 使用 FOR UPDATE。
关于mysql - 如何在数据库中存储已付款和未付款的订单？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29350481/