在Web应用程序中存储信用余额的最佳实践

Question

我正在创建一个网络应用程序，用户可以在其中购买积分（使用真钱）并将其花在事情上。

每次用户购买或花费信用时，我都需要保留历史记录。

我经常需要知道用户当前的信用余额。

我通常认为两次存储相同数据的原则是不好的做法，即由于我有信用余额增加和减少的历史记录，我不应将余额本身存储为单独的字段。

但是，每次用户打开新页面（将显示其当前余额）时计算此余额似乎有些过分。另一方面，将它存储在数据库中或存储在Web服务器上似乎是错误的，只是为了防止系统每次都必须解决它。

有没有人有这方面的经验和/或知道这种情况的推荐最佳做法是什么？

Answer 1

我已经开展了几个具有类似要求的项目，并且在运行中计算当前余额没有任何问题 - 它是最不易出错的解决方案，而这种查询是大多数数据库的设计目的;除非你在Facebook级别的流量网站上工作，"select sum(transactionValue) from transactions where userID = ?"之类的内容应该非常快。

在其他地方存储余额 - 实际上重复它 - 有可能引入微妙的错误和差异，“缓存”值与基础交易不同步;实现这一目标所需的工作量可能很大。

Answer 2

Denormalization有它的位置。例如，包含论坛主题的表格也有PostCount列，而不是为每个主题执行COUNT(posts)。如果您担心一致性，并且您应该，您可以安排定期检查（例如，来自或来自给定用户的每个事务），在那里测试每个用户的Balance是否与其事务的总和相匹配。

Answer 3

不要计算每个请求的贷方余额 每个用户的贷方余额都是您应该维护的。

将其保存在您的数据库中 这样你就不用担心并发了 当用户使用您的应用程序时，使用事务递增递减此值 数据库确实针对重复选择进行了优化，所以再次让你的数据库负责处理。

Answer 4

计算余额需要时间吗？如果没有，只需用SQL实时计算。

但是，当你的交易日志变得越来越大（数百万行）时，我预计将来会出现问题。当事务日志中的选择查询需要时间时，则需要缓存并预先计算余额并将其存储在数据库中。