产品一组销售的数据模型

Question

假设我有一个电子商务，其数据模型如下所示，它允许Sale描述单个Product的销售方式。该部门允许以不同的方式(不同的定价，或在不同的时间点提供)多次销售产品。这是伟大的，当一个销售是出售一个单一的产品。

Sale

• product_id (销售属于产品)
• 其他报价细节，如价格、销售到期日、营销内容等。

产品

• 产品有很多销售
• 真实的产品细节，如名称、照片、制造商描述等。

问题是:如何改进这个数据模型以允许销售有许多产品？

例如，要创建一个包含1的产品A和1的产品B的捆绑包，所以如果一个客户想要这些捆绑包的quantity=3，他们将总共得到3A和3B的包。

也可以是一种产品的倍数出售。在这种情况下，销售将是5个产品C，因此，如果一个客户想要quantity=3的这些捆绑，他们将得到15个产品C。

到目前为止，我最好的想法是增加一个新的表。这将允许销售引用许多订单，这些订单描述了包中的内容。

订单

• 属于产品
• 属于销售
• 包中的数量

但如此大规模的重构是一项艰巨的任务。由于各种原因，sale.product出现在代码库中的次数是巨大的。每一种情况都需要在代码中进行修正，而且可能还需要表示。

因此，在我们对这一方法作出过多承诺之前，我想知道是否还有一线希望我还没有看到，或者我的未来是否充满了这场史诗式重构的痛苦和危险。

Answer 1

在过去，我在那些这样做的公司看到的是两种方法中的一种：

1. “包”是一个单独的产品。它作为自己的产品放入数据库，作为自己的产品存储在库存中，然后从库存中移除，并作为自己的产品发货。不需要重构，但将产品捆绑在库存中，如果发生故障，可以单独出售。它的优点是可以定制为一个捆绑；即成本可以是不同的个别产品。
2. “捆绑”是一种“材料清单”，最终形成一种成品。需要一种完全不同的方法，大量的重构，但保持单个产品在货架上的完整性。会有很多重复，因为每个单独的产品仍然需要自己的材料清单，其中包含一个项目(本身)。

如果我这么做的话，我会找到一种方法，把包作为“快速输入”来推销。它的工作方式有点像GUI宏；您可以从产品列表中选择一个包，它会自动向发票中添加所需的各个行项(和数量)。你仍然需要一个“材料清单”来实现它，但你不需要重构整个系统。