GWe*_*Wed 13 mysql schema database-design audit data-integrity
我正在设计我的第一个电子商务模式。我已经阅读了一段时间的主题，并且对 anorder_line_item和 a之间的关系感到有些困惑product
一个product可以被购买。它有各种细节，但最重要的是unit_price。
Anorder_line_item有一个外键，指向product_id购买的、quantity购买的和unit_price客户购买产品的时间点。
我读过的大部分内容都说应该明确添加unit_priceon order_line_item（即不通过 引用product_id）。有道理，因为商店将来可能会改变价格，这会弄乱订单报告、跟踪、完整性等。
我不明白的是，为什么直接将unit_price值保存到order_line_item?
创建一个记录unit_pricea 更改的审计/历史表不是更好product吗？
当order_line_item被创建，所述的外键product_audit表，并将该价格可以从那里检索（通过引用）。
在我看来，使用这种方法有很多好处（减少重复的数据、价格变化历史等），那么为什么不更频繁地使用它呢？我还没有遇到使用这种方法的电子商务模式的例子，我错过了什么吗？
UDPATE：我的问题似乎与Slowly Changed Dimension 相关。我仍然感到困惑，因为缓慢变化的维度与数据仓库和 OLAP 相关。那么，缓慢变化的维度类型可以应用于我的主要业务事务流程数据库 (OLTP) 吗？我想知道我是否混合了很多概念，非常感谢一些指导。
Chr*_*xon 10
正如您所确定的，在订单上存储价格可以使技术实施更容易。有许多商业原因为什么这可能是有益的。
除了网络交易外，许多企业还通过其他渠道支持销售，例如：
在这些情况下，订单可能会在交易发生后的某个时间输入系统。在这些情况下，可能很难甚至不可能正确识别应使用哪个历史价格记录 - 将单价直接存储在订单上是唯一可行的选择。
多渠道往往带来另一个挑战——同一种产品的不同价格。电话订单的附加费很常见 - 一些客户可能会自行协商折扣。您可能能够在您的产品架构中表示所有渠道的所有可能价格，但将其合并到您的订单表中可能会变得（非常）复杂。
在任何允许协商的地方，将历史价格与商定的订单价格联系起来变得非常困难（除非代理商的协商限制非常窄）。您需要在订单本身上存储价格。
即使你只支持网络交易并且有一个相对简单的定价结构，仍然有一个有趣的问题需要克服——如何处理飞行交易的价格上涨？企业是否坚持要求客户必须加价，或者他们是否遵守原价（当产品加入购物篮时）？如果是后者，则技术实现很复杂 - 您需要找到一种方法来确保您在会话中正确维护价格版本。
最后，许多企业开始使用高度动态的定价。给定的产品可能没有一个固定的价格——它总是在运行时根据一天中的时间、对产品的需求等因素进行计算。在这些情况下，价格可能不会首先与产品相对应！