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

【问题标题】：should the user's Account balance be stored in the database or calculated dynamically?用户的账户余额应该存储在数据库中还是动态计算？
【发布时间】：2011-09-14 13:46:51
【问题描述】：

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

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

交易

标识（PK）
帐户 ID
类型
日期时间
金额
等等……等等……

账户余额

TransactionId (PK/FK)
余额金额

【问题讨论】：

如何动态计算，然后存入数据库。这意味着用户可以随着时间的推移查看他的余额。
保留更改日志并为实际数据保留一个“软”记录。软记录只是一个包含大多数余额数据的最新字段。更新单个事务中的所有字段，然后就可以了。对于一个简单的游戏，我只保留一个“金额”字段。

标签： c# application-design architecture database-design

【解决方案1】：

您需要问自己几个问题： 1) 谁将拥有计算？ 2) 谁需要结果？

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

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

这种情况下的解决方案 - 要么存储计算，要么让数据库成为计算的所有者，并拥有一个返回结果的 sql 函数。

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

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

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

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

【讨论】：

【解决方案4】：

当前余额已经可用！它是账户最后一笔交易的余额：

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

余额必须作为每笔交易的一部分进行计算和存储否则系统将无法扩展... 此外，如果您不存储余额，则您没有检查和余额（因为余额必须等于以前的余额加上新的贷方减去新的借方）

【讨论】：

【解决方案5】：

如果您的应用程序没有从数据库中检索数据以进行余额计算，而您需要余额，我建议您应该计算余额或存储在数据库中。
如果您需要经常更新余额并且它是基于多个表格动态更改的，那么您应该使用 表格视图 而不是触发器。

【讨论】：