标签：mysql database-design data-integrity schema audit

我正在设计我的第一个电子商务架构.我一直在阅读这个主题一段时间,对于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)吗？我想知道我是否混合了很多概念,非常感谢一些指导.

解决方法:

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

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

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

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

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

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

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

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

标签：mysql,database-design,data-integrity,schema,audit
来源： https://codeday.me/bug/20190805/1588200.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。