问产品采购历史数据库设计

EN

比如说我开了一家卖某种产品的商店。产品具有典型的属性，最重要的是价格。当客户进行购买时，会生成一张发票，该发票引用一个或多个产品。

问题:如果商店的员工更新了产品，我们可能无法计算出客户为某一特定商品支付了多少钱，因为该产品的价格已经更新。如何处理这个用例？我能想到三个选择：

1. 向products表中添加一个version列。更改时，插入新行并增加版本号，而不是更新版本号。当我从购买中引用一个产品时，我会引用一个特定版本的产品，所以在购买时我总是知道一个产品的成本。

我看到的问题是，忽略性能和不断增加的存储需求，每当我需要更新价格(或其他产品属性)时，我需要更新该项目的所有外键引用。在我的数据库中，我可能有十几个这样的表，其中大多数不需要像过去的价格那样的“历史”信息。

1. 创建一个单独的product_history表，其中包含product表的列以及所有以前版本的附加version和change_time列。在更新产品表时，我将将先前版本保存到历史表中。购买和其他需要历史信息的表将引用product_history中的行，而不是product中的行。
2. 向产品中添加一个version列，每次更新都会增加该列。当有购买时，将产品复制到purchase_product表中。购买表将引用purchase_product，而不是product。我只保留一个产品的每一个版本一行，所以当很多人购买相同的产品时，不用担心表的尺寸会爆炸。

3看起来稍微好一些，因为我只保留我实际需要的产品的版本(不是针对产品价格的每一个变化)。然而，这意味着当一个产品没有销售时，我将无法进行分析，因为(比如说)价格太高……

或者，有更明显的解决办法吗？