Sql 事务聚合的最佳实践数据库设计是什么？

我正在设计一个数据库，它将保存事务级数据。它的工作方式与银行账户相同——借记/贷记账号

获取这些事务聚合的最佳/最有效的方法是什么

我在考虑使用一个汇总表，然后将这些汇总表添加到今天的交易列表中，以得出每个账户的余额

我希望这是可扩展的（即10亿笔交易），因此不希望必须对主事实表执行数据库点击，因为它将需要查找与所需账号相关的所有借项/贷项，可能需要扫描10亿行

---

谢谢，任何帮助或资源都会很棒。

做一个面向对象的设计，为对象创建表，例如帐户、事务等。这里有一个很好的参考。但是网络上还有很多关于OODBMS的讨论。当我开始做OODBMS时，我给出的参考资料只是我的基础。

（已经在银行工作了近10年。下面是它的实际操作方法）

TLDR：你的想法很好

您不时将余额存储在其他地方（“结转余额”）。例如，每月左右（或平均一定数量的交易）。为了计算实际余额（或过去的任何余额），您将所有相关交易累加，直到您保留的最新余额（“结转余额”），当然，您需要添加

“当前”余额不存在于任何地方。如果你一直更新这个平衡，你会遇到锁定问题。（在真实的银行中，几乎每一笔交易都会打到一些银行内部账户。有大量的银行内部账户可以获得法律要求的数据。这些账户经常被打，因此当你想在每笔交易中更新它们时，会导致锁定问题。相反，每笔交易都只是插入-即使结转余额也只是插入项）

此外，在实际银行中，您有许多使用案例使这种方法更为有利：

• 能够在任何时间获得过期余额-能够根据任何时间的不同日期（例如，起息日期与交易日期）获得余额
• 撤销/取消本身就是一种乐趣。想象一下，从两周前开始撤销一笔交易，但仍保持上述所有操作

你看，说来话长。但是，您的问题的答案是：是的，您不能累积不断增加的交易数量，您需要保持中间余额，以限制累积的数量（如果需要）。在主表中点击有限的行数应该没有问题

---

确保您的主要查询使用了。

谢谢您的回答。你的回答很有道理，我想也有类似的过程。就从“结转余额”表和最近交易列表中获取余额而言，您是否只需使用union all将它们组合在一起，而不是对组合集应用聚合，以获得单个余额。谢谢你的帮助