我正在设计我的第一个电子商务架构.我一直在阅读这个主题一段时间,对于order_line_item和产品之间的关系有点困惑

可以购买产品.它有各种细节,但最重要的是unit_price.

order_line_item具有购买的product_id的外键,购买的数量以及客户购买产品的时间点的unit_price.

我读过的大部分内容都说明了order_line_item上的unit_price应该被明确添加(即不通过product_id引用).有道理,因为商店可能会在未来改变价格,这会弄乱订单报告,跟踪,完整性等.

我不明白的是,为什么直接将unit_price值保存到order_line_item？

创建记录产品的unit_price变化的审计/历史记录表会不会更好？

创建order_line_item时,会添加product_audit表的外键,并且可以从那里检索价格(通过引用).

在我看来,使用这种方法有很多好处(更少的数据重复,价格变化历史等),为什么不经常使用它？我没有遇到使用这种方法的电子商务架构的例子,我错过了什么？

UDPATE：看起来我的问题与Slowly Changing Dimension有关.我仍然感到困惑,因为Slowly Changing Dimension与数据仓库和OLAP有关.那么,Slowy Changing Dimension类型可以应用于我的主要业务事务处理数据库(OLTP)吗？我想知道我是否混合了很多概念,非常感谢一些指导.

解决方法:

正如您所确定的那样,将价格存储在订单上会使技术实施变得更加容易.虽然这可能有益,但有许多商业原因.

除了网络交易,许多企业还通过其他渠道支持销售,例如：

>通过电话
>销售代理“在路上”
>在实际位置(例如商店,办公室)

在这些情况下,订单可以在交易发生后的某个时间输入系统.在这些情况下,很难不能正确识别应该使用哪个历史价格记录 – 将单价直接存储在订单上是唯一可行的选择.

多渠道经常带来另一个挑战 – 同一产品的价格不同.电话订单的附加费很常见 – 有些客户可以自行协商折扣.您可能能够代表产品架构中所有渠道的所有可能价格,但将其纳入您的订单表可能会变得非常复杂.

在允许谈判的任何地方,将价格历史与商定的订单价格联系起来变得非常困难(除非代理商具有非常狭窄的谈判限制).您需要将价格存储在订单本身上.

即使您只支持网络交易并且具有相对简单的定价结构,仍然有一个有趣的问题需要克服 – 如何在飞行交易中处理价格上涨？企业是否坚持要求客户支付增加费用或者是否遵守原始价格(当产品被添加到购物篮中时)？如果是后者则技术实现很复杂 – 您需要找到一种方法来确保您正确地维护会话中的价格版本.

最后,许多企业开始使用高动态定价.对于给定产品,可能没有固定价格 – 它总是在运行时根据诸如时间,产品需求等因素计算.在这些情况下,价格可能不会首先存储在产品中！