来自第一次尝试自己组装数据库模型的应用程序程序员的另一个问题。
在我的应用程序中，有用户、帐户和交易。我最初在 3NF 中拥有所有表格（或者我相信）。然后我决定给用户添加一个平衡字段，主要是因为我的代码会开源，我不希望人们通过更改 PHP 代码来搞乱系统的业务逻辑。所以触发器和存储过程会更新余额。
现在有一个新要求，用户将在他们的帐户页面上列出他们使用余额列进行的所有交易，这样他们就可以看到他们的余额如何随着每笔交易而变化。当然，事务和用户在不同的表中。
该怎么做？我当前的解决方案草图看到一个 balance_history 表，其中包含 transaction_id 和 user_id 的外键。还有什么建议吗？谢谢。
将计算值存储在数据库中总是充满潜在的错误。话虽这么说，它只是一种缓存技术，而且现在已经很好地理解了缓存。
但是，每次访问时只计算帐户页面上的运行余额是否很昂贵？我们在这里只讨论加法和减法。也许只需获取缓存的最终余额，然后从它向后计算每个事务的运行余额，并且可以节省大量维护建议的 balance_history 表的工作。
我还要补充一点，如果允许插入或更新旧事务，那么 balance_history 表将很难更新。然后，您必须为该用户更新每个连续交易以更正运行余额。
Alexey Sviridov 建议使用视图作为运行天平的建议是一个很好的建议，尽管它们可能很难编写（尤其是为了高效运行）。Oracle 的分析功能非常适合这类事情，但我不确定 MySQL 是否有等效功能。
如果您的交易表不是很大，我建议您从用户表中删除余额列。如果您已经有一个事务表，为什么还要使用 balance_history？我强烈建议您从触发器中删除任何业务逻辑！只有存储过程。我建议仅将触发器用于真正透明的操作（审计、复杂验证等）。总之，我认为您应该从用户表中删除余额列，而是编写视图（例如“UserBalance”）加入用户和事务表。从触发器中删除任何业务逻辑，改为调用适当的存储过程。仅使用交易表来显示余额历史记录。这对于不是很大的表都是正确的（3-4 百万条记录是可以的）。对于非常大的数据库，您需要使用分布式缓存、垂直数据库等。