我正在创建一个Web应用程序，用户可以在其中购买贷项（使用真实货币）并将其用于物品。在Web应用程序中存储贷项余额的最佳实践
我将需要保持每次用户购买或花费信用的历史。
我经常需要知道用户的当前贷方余额。
我通常工作的原则是两次存储相同的数据是不好的做法，即因为我有一个所有信贷余额增加和减少的历史，我不应该把余额本身存储为一个单独的字段。
但是，每次用户打开一个新页面（将显示其当前余额）时，计算此平衡似乎有点矫枉过正。另一方面，将它存储在数据库或网络服务器的内存中似乎是错误的，只是为了防止系统每次都必须处理它。
有没有人有这方面的经验和/或知道什么建议的最佳做法是这种情况？
我从事过几个具有相似需求的项目，在即时计算当前余额方面没有任何问题 - 这是最容易出错的解决方案，这种查询是大多数数据库设计的目的;除非你在一个Facebook流量级别的网站上工作，像"select sum(transactionValue) from transactions where userID = ?"这样的网站应该是非常快的。
在其他地方存储余额 - 重复它 - 实际上 - 可能会引入细微的错误和差异，“缓存”值与基础事务不同步;获得这项权利所需的工作量可能很重要。
Denormalization确定它的位置。例如，一个包含论坛主题的表格也有一个PostCount列，而不是为每个主题做一个COUNT(posts)。如果您担心一致性，并且您应该，您可以安排每个用户的Balance与他们的交易总和相匹配的定期检查（例如，来自或发给给定用户的每次交易）。
不计算每个请求的贷方余额。
每个用户的贷方余额是你应该维护的。
保留在您的数据库中。
这样你就不必担心并发。
当用户使用您的应用程序时，使用事务来增加递减此值。
数据库确实对重复选择进行了优化，所以再次让你的db处理这个问题。
计算余额是否需要时间？如果不是，只需使用SQL实时计算。
但是，当您的交易日志变得越来越大（数百万行）时，我正在预见未来的问题。当从事务日志中选择查询需要时间时，那么是时候缓存并预先计算余额并将其存储在数据库中。
是的问题是，当检查发现Postcount！= COUNT（Posts）时该怎么办。 – GGG 2013-03-21 09:34:58
@GGG当然，实际的帖子表（或您的交易日志）在出现差异的情况下是领先的。 – CodeCaster 2013-03-21 09:52:09