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

Question

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

获得这些交易聚合的最好/最有效的方法是什么。

我正在考虑使用汇总表，然后将它们添加到今天的交易列表中，以便得出每个账户有多少(即余额)。

我希望它是可扩展的(即 10 亿笔交易)，所以不想对主要事实表执行数据库命中，因为它需要找到与所需帐号扫描相关的所有借方/贷方可能有十亿行。

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

Answer 1

(在银行工作了将近 10 年。这是实际完成的方式)。

TLDR:你的想法很好。

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

“当前”余额不会在任何地方保留。如果您一直更新此余额，就会遇到锁定问题。 (在真实的银行中，几乎每笔交易都会影响一些银行内部账户。有很多银行内部账户可以获得法律要求的数字。这些账户经常受到影响，因此当您进行交易时会导致锁定问题我想用每笔交易更新它们。相反，每笔交易都只是插入——甚至结转余额也只是插入)。

同样在真实的银行中，您有许多使这种方法更受欢迎的用例:

• 能够随时获取过期余额 - 能够随时获取基于不同日期的余额(例如起息日与交易日)。
• 撤销/取消本身就是一种乐趣。想象一下，要撤销两周前的交易，并且仍然保持上述所有操作。

你看，这是一个很长的故事。但是，您的问题的答案是:是的，您不能累积越来越多的交易，您需要保持中间余额以限制累积的数量(如果需要)。命中主表的行数有限，应该没有问题。

确保您的主查询使用 Index-Only Scan .