如何处理更新后影响历史交易的数据库关系变更及属性留存问题

你提出的在payments表直接存储交易对应折扣率的思路，是交易类数据建模中经过行业验证的正确实现，本质上符合 「交易记录留存时点快照」 的设计原则，完全不是过度设计。

如果所有历史支付记录都直接关联查询折扣卡、商品表的当前实时属性计算金额，后续遇到规则或基础数据变更时，会直接产生数据错误：

• 当所有折扣卡的折扣率统一下调时，所有历史上按5%规则完成的支付，关联当前值计算会被错误归为4%的优惠水平，导致历史营收、优惠成本的统计完全失真
• 当员工修正之前录错的商品售价时，所有关联商品表实时值计算的历史支付金额，会被直接替换成修正后的数值，和交易发生时实际收付的金额完全不匹配

除了现有表结构里已经存的amount（商品原价）、amount_discounted（折后金额），建议至少在payments表补充存储这些交易时点的关键属性：

• 交易发生时实际适用的折扣率reduction_rate
• 可选补充：如果业务中折扣规则还和折扣卡等级、适用品类、有效期限定这类属性相关，也可以在支付落库时把这些影响金额计算的规则值存为快照，避免后续折扣卡升级、规则调整带来的历史数据偏差

• 不要因为“多存字段会增加存储开销”否决快照方案：相比历史交易对账、财务审计、营收统计失真带来的业务风险，多存几个数值类型字段的存储成本几乎可以忽略
• 不要尝试用实时关联查询的方式回溯计算历史支付的金额：哪怕当前维度表的属性从来没有变动过，只要后续业务规则发生调整，历史计算逻辑就会出错，这是交易系统数据建模的基本红线
• 修正员工录入错误的商品金额时，绝对不能直接覆盖已经生成的历史支付记录的快照值：错误修正需要走单独的交易冲正、补录流程，原已完成的支付记录必须完整保留交易发生时的真实快照

内容的提问来源于stack exchange，提问作者Pouissante