我正在为一家类似银行的机构建立一个BI系统。该系统应管理信贷合同、发票、付款、罚款和利息。
现在，我需要做一个方法来建立一个发票。我得计算一下顾客现在要付多少钱他有一笔债务，必须偿还他还得付利息。如果他逾期未付，他每迟到一天就要被罚款。
我想有两种方法：
只有一个原始状态-合同的原始状态每次计算客户每月必须支付的款项时，考虑实际支付的款项。
通过不断地建立中间状态，从最后一个中间状态开始，只考虑这两个中间状态之间发生的事件。这意味着有一个定期（每日、每月）执行的作业，该作业获取最后保存的状态，应用更改（到期付款、实际付款、全球常数的更改，如中央银行控制的罚款率），并保存结果状态。
第一种变体的优点：
总是真实的。如果对过去的日期进行了更改（一个人在向银行付款5天后带着一张已付款的发票来），这些更改将正确地反映在结果中。
第一个变体的缺陷：
计算需要很长时间
如果正确的数据因输入日期的操作而更改，则使用当前结果打印的文档可能会有所不同。
第二种变体的好处：
工作速度快，聚合数据始终可用于搜索和报告。
计算更简单
第二种变体的缺陷：
易受失败作业的影响。
过去的错误一直传播到最后的结果。
如果来自过去事务的新数据到达，中介结果就无法更改（它可以，但很难，而且有很多含义，所以我宁愿将其标记为tabu）
如果一个未完成的事务存在（未支付的已发出的发票），作业不能成功地执行，并且没有问题。
还有别的办法吗我能把这两者的好处结合起来吗你遇到过的其他类似系统中使用的是哪一个？请分享经验。
最佳答案
这种性质的问题总是比最初出现的问题更复杂这个
是我喜欢称之为Rumsfeldian problem of the unknown unknown的结果。
基本上，不管你现在做什么，都要准备好对未来的任意规则进行调整。
这是一个艰难的提议。可能对未来产生重大影响的一些可能性
您的计算模型是过期付款、调整和收费。
可免除的利息期也可能成为一个问题（特别是如果是过期的）。要求
提供基于“已知”的各种时间点（PIT）计算
该PIT（过去的观点）或考虑参考PIT之后发生的交易
追溯到参考之前的一个坑（过去的当前视图）。这种性质的计算可以是
头上真的很痛。
我的建议是从头计算（即第一个变量）仅实现优化（如第二个变量）
当需要满足性能约束时。从头开始做计算是一项计算密集型工作
模型，但通常是更灵活的适应意外的左转。
如果性能是一个问题，但复杂因素的频率（如过期交易）
是相对较低的，你可以探索一个混合模式采用最好的两个变种在这里您存储
当前状态并向前计算
仅使用自上次存储状态以来发布的事务来创建新的当前状态如果你击中了
“复杂”重新做了整个帐户从
开始重建当前状态。
从长远来看，能够在不触发重写的情况下适应意外情况可能更为重要
比现在缩短计算时间还多在必要时才对计算模型施加限制。保存
当前状态通常会带来一些内置的假设和限制，这些假设和限制减少了
适应未来的需求。