Ruby on rails 4 对于购物应用程序，构建一个或两个模型的优缺点是什么？

其他背景：

用户可以在每次购物时购买一个或多个商品。我试图找出两种方法的优缺点。我已经写下了我认为每种方法的优点，不需要指出缺点，因为一种方法的缺点可以写成另一种方法的优点，但是我想从社区得到反馈

方法1：

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

优点：

一般来说比较简单，一个模型总是好的 与项目单独定价和取消/退款这一事实很好地吻合，即，在购买层面上不会出现任何折扣或费用，1不会分配给单个项目，2不会符合其自身的模式 方法2：

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

优点：

对于业务而言，我认为有两种方法更容易：1更容易运行分析，以确定人们每次进行购买交易时想要购买的物品数量。方法1并非不可能，但方法2肯定更容易，也许最重要的是：2从实现角度来看，向履行中心发送一份包含多个项目的采购似乎更容易，因为交付日期都是相同的，而不是一堆项目，然后他们必须再次聚合。方法1并非不可能，但方法2更容易

---

这可能会变得相当复杂，在过去，我使用了更高级的版本2。您希望尽可能对数据进行规范化查找数据库规范化以获取更多信息，以便更轻松地运行报告，同时保持数据的一致性并减少重复。在一些真实场景中，不可能总是完全正常化，处理性能考虑也在其中起着作用-如果完全正常化数据，您将数据分割成许多小块，例如表中的行，但要重建数据，您必须从许多位置检索数据，例如多个数据库查询，这会影响性能

---

使用第二种方法，在编写代码之前，彻底计划如何构建数据结构。对于一个结构良好的模型，在将来扩展系统应该相当简单。扁平结构可能会成为维护的噩梦。

是的，在规范化和性能之间的权衡方面，您比我表达得更好。我问这个问题是因为我正在重新设计一个应用程序，但最初的版本有5个表支持2个，这有点烦人。但我还是会同意的，谢谢！