数据库模型和计算余额，mysql

另一个问题来自一个应用程序程序员，他第一次尝试自己组装一个DB模型

在我的应用程序中，有用户、帐户和交易。我最初把所有的表都放在3NF中（我相信是这样）。然后我决定给用户添加一个平衡字段，主要是因为我的代码将是开源的，我不希望人们通过更改PHP代码来扰乱系统的业务逻辑。因此，触发器和存储过程会更新平衡

现在有了一个新的要求，用户在他们的账户页面上有一个列表，列出他们在余额栏中所做的所有交易，这样他们就可以观察每笔交易中余额的变化。当然，事务和用户位于不同的表中

怎么办？

---

我当前的解决方案草图看到一个余额历史记录表，其中包含事务id和用户id的外键。还有其他建议吗？谢谢。

在数据库中存储计算值总是充满潜在错误。这就是说，这只是一种缓存技术，缓存现在已经被很好地理解了

然而，每次访问账户页面时，仅仅计算账户页面上的运行余额是否有那么昂贵？我们只是在讨论加法和减法。也许只需要获取缓存的最终余额，并从中向后计算每个事务的运行余额就可以了，这样就可以节省大量维护建议的balance_history表的工作

我还想补充一点，如果允许插入或更新较旧的事务，那么balance_history表将很难更新。然后，您必须为该用户更新每个后续事务，以更正运行余额

---

Alexey Sviridov建议对运行中的余额使用视图，这是一个很好的建议，尽管它们可能很难编写（尤其是为了高效运行）。Oracle的分析功能在这方面非常好，但我不确定MySQL是否有类似的功能。

如果您的事务表不是很大，我建议您从users表中删除balance列。如果您已经有一个事务表，为什么要平衡历史记录？ 我强烈建议您从触发器中删除任何业务逻辑！只有存储过程。我建议只对真正透明的操作（审计、复杂验证等）使用触发器。 总之，我认为您应该从users表中删除balance列，而不是编写连接用户和事务表的视图（“UserBalance”）。从触发器中删除任何业务逻辑，改为调用优先存储过程。仅使用交易记录表显示余额历史记录。 对于不太大的表（3-4百万条记录就可以了），这一切都是正确的。对于非常大的数据库，您需要使用分布式缓存、垂直数据库等