存储的金融交易是否应该包括一些数据冗余?

Mar*_*hoh 8 normalization database-design

我目前在下表中存储金融交易(为简洁起见已缩短):

id INT
start DATETIME
end DATETIME
rate INT
usage INT
usage_fee INT
amount INT
commission_pct INT
payout INT
currency VARCHAR(5)
Run Code Online (Sandbox Code Playgroud)

向客户收取的总金额计算如下: amount = (end - start) * rate + usage * usage_fee

该平台收取以下费用/佣金: commission = amount * (commission_pct / 100)

服务提供商收到的付款是: payout = amount - commission

现在在上表中,存储支出在技术上是多余的,因为它可以按上图所示进行计算。我的问题是,存储这些类型的有关数据冗余的金融交易的常见方式/约定是什么?

例如,我正在考虑也存储的结果(end - start) * rateusage * usage_fee分别在该表中,除了它们的总和(量)。

我看到这样做的优点是:

  • 将相应金额发送到“支付提供商的 API”时没有(四舍五入)错误,即用户最终支付的金额与存储在数据库中的内容完全相同,而不是将计算值发送到所述 API
  • 易于查询和分析

这些专业人士是否有效,或者您会建议我完全规范化表格并在需要时计算值吗?

我知道根据“数据库设计原则”对表格进行规范化是正确的答案,但由于我正在处理财务数据,因此我不确定我是否 100% 愿意使用计算值。


佣金率不是每笔交易特定的,但收取的 Commission_pct 很可能在未来发生变化,因此它与每笔交易一起存储。当然,如果存储的是实际的“佣金金额”,则无需存储佣金百分比。

当时使用的 Commission_pct 和 rate 存储在表中,这就是为什么将来为后续交易更改这些不会有问题并且永远不会编辑现有交易的原因。此外,只有一个受控应用程序可以访问数据库。如果公式在未来发生变化,不计算和存储结果将是一个问题。我倾向于应用程序计算这些值并一举存储“原始”和计算值。

Dav*_*oft 13

像这样存储计算结果是很常见的,这样您就可以记录金融交易的事实,而不是您认为应该发生的事情。还因为存储结果允许您随着时间的推移执行调整和更改计算。