对于购物应用程序，构建ONE模型或TWO模型的优缺点是什么？

Question

附加背景：

用户每次购物都可以购买一件或多件商品。我试图找出两种方法的优点/缺点。我已经写出了我认为每个人的优点（不需要调用缺点，因为一个人的Con可以写成另一个的Pro），但我希望得到社区的反馈

方法1：

构建单个模型，例如Items，其中包含事务中每个项目的记录。

优点：

• 通常更简单，一个模型总是很好
• 与物品定价和取消/单独退款这一事实保持一致（即，在购买水平上没有任何折扣或费用，或者1）不分配给个别物品或2）不值得自己模型）

方法2：

构建两个模型，例如，购买和项目，其中，购买是表示该交易的父记录，而项目是表示在该交易中购买的每个项目的子记录。

优点：

• 对于企业而言，我认为通过两种方式更容易：1）运行分析更容易确定每次进行购买交易时人们想要购买多少商品（方法1并非不可能）但是使用方法2）肯定更容易，也许最重要的是：2）从履行的角度来看，发送履行中心似乎更容易一次购买包含许多物品，因为交货日期都是相同的，而不是一堆物品然后他们必须聚合（再次使用方法1并非不可能，但使用方法2则更容易）

Answer 1

这可能变得非常复杂，过去我使用了更高级的＃2版本。您希望尽可能地标准化数据（查找数据库规范化以获取更多信息）以便更容易地运行报告，还要保持数据的一致性并减少重复。在某些实际场景中，并不总是能够完全规范化，并且处理性能考虑也会起到一定的作用 - 如果您完全规范化数据，则将数据拆分为许多小块（例如表中的行），但要重建数据然后，您必须从性能受损的许多位置（例如，多个数据库查询）中检索它。

使用＃2，在您对数据进行过深的编码之前，彻底规划如何构建数据。对于结构良好的模型，将来扩展系统应该相当简单。扁平结构可能成为维持的噩梦。