对于购物应用程序，建立ONE模型或TWO模型有什么优点/缺点？

Question

附加上下文：

用户每次购物时都可以购买一件或多件商品。我试图找出两种方法的优缺点。我已经写出了我认为每个人的优点（无需召唤出Cons，因为一个Con可以写成另一个的Pro），但我想从社区获得反馈

方法1：

构建一个单一的模型，例如Items，其中每个项目在事务中都有一个记录。

优点：

• 一般比较简单，一个模型总是好的
• 良好比对的事实是，项目的价格，并取消/单独退还（即有没有真的什么优惠或费用在发生这将是1）无法被分配到个别项目或2）不值得自己的模式购买水平）

方法2：

构建两个模型，例如Purchases和Items，其中Purchases是代表该交易的父记录，而Items是表示在该交易中购买的每件物品的子记录。

优点：

• 对于商家来说，我认为这是在两个方面简单：1）它更容易运行分析，以找出例如人们想要多少个项目在每次进行购买交易时间买（在方法1中这不是不可能的，但在方法2中肯定更容易），也许最重要的是：2）从履行的角度来看，发货履行中心似乎更容易一个采购与许多项目，因为交货日期都将相同的，而不是一堆物品，他们然后必须聚合（再次这是不可能的方法1，但方法2更容易）

Answer 1

这可能会变得非常复杂，并且在过去我已经使用了更为先进的＃2版本。您希望尽可能标准化您的数据（查找数据库标准化以获取更多信息），以便更轻松地运行报表，同时保持数据的一致性并减少重复。在一些真实世界的场景中，并不总是可以完全标准化，并且处理性能考虑也会在某些时候扮演重要角色 - 如果您完全规范化了数据，则会将数据分成许多小块（例如表中的行），但要重建数据那么你必须从多个位置（例如多个数据库查询）中检索它，这会影响性能。

与＃2一起去吧，彻底计划你在数据编码之前如何构造数据。对于一个结构良好的模型，未来在系统上扩展应该是相当直接的。一个扁平结构可能成为一个噩梦来维护。