应该将用户的帐户余额存储在数据库中还是动态计算？

用户的帐户余额是应该存储在数据库中还是动态计算？

为了获得准确的结果，计算它是动态有意义的，但是当有很多用户并且数据库变得非常大时，它可能是一个问题？

交易

账户余额

为了保持准确的审核，您应该记录影响用户帐户余额的每笔交易。这意味着您可以动态计算余额，但出于性能原因，我也会存储余额。为了确保平衡是正确的，我会有一个每日工作运行，从头开始重新计算余额。

我认为这是一个很好的问题。每次计算显然都很容易，但可能会导致大量不必要的计算，从而导致性能下降。

但是将当前余额存储在某个其他表中可能会导致数据并发性问题，其中构建聚合的数据被修改为与聚合不同步。

也许一个幸福的媒介是在事务表上有一个sql触发器 ，它更新该用户的插入或更新的聚合值。

你需要问自己一些问题：1）谁将拥有计算？ 2）谁将需要结果？

现在，如果计算的所有者是唯一需要它的人 – 或者如果其他需要它的人将从所有者那里获得它，那么就不需要存储计算。

但是，在大多数实际运行很长时间的应用程序中，计算结果可能最终会在其他地方需要。例如，像SQLReportingServices这样的报表应用程序将需要计算结果，因此如果计算的所有者是Web应用程序，则会出现问题。报告服务（仅与数据库对话）如何获得结果？

在这种情况下的解决方案 – 存储计算或使数据库成为计算的所有者，并具有返回结果的sql函数。

就个人而言，我倾向于采用非纯粹方法 – 我将计算结果存储在数据库中。空间很便宜，读取时的响应时间比读取+函数调用快。

目前的余额已经可用！它是帐户上次交易的余额：

select top 1 [Balance] from dbo.Trans where [AccountID] = @AccountID order by [TranID] desc

余额必须计算并存储为每笔交易的一部分，否则系统将无法扩展……如果您没有存储余额，则您没有支票和余额（因为余额必须等于以前的余额加上新的信用额度新的借记）