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

Question

我正在设计一个包含事务级数据的数据库。它的工作方式与银行账户相同 - 账户号码的借方/贷方。

获取这些交易汇总的最佳/最有效方式是什么？

我正在考虑使用汇总表，然后将这些汇总表添加到今天的交易清单中，以便得出每个账户有多少（即有余额）。

我希望这是可扩展的（即10亿次交易），因此不希望必须对主要事实表执行数据库命中，因为它需要找到与所需帐号扫描关联的所有借方/贷方可能有十亿行。

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

Answer 1

（已在银行工作了近10年。以下是实际完成的方法。）

TLDR：你的想法很好。

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

“当前”余额不会保留在任何地方。如果你一直在更新这种平衡，那么你可能会遇到锁定问题。 （在真实银行中，您几乎每笔交易都会触及一些银行内部账户。有很多银行内部账户能够获得法律要求的数据。这些账户经常受到影响，因此会导致锁定问题我希望每次交易都更新它们。相反，每个交易都只是插入 - 即使结转余额只是插入。）

同样在真实银行中，您有许多用例使这种方法更有利：

• 能够随时取回日期余额 - 能够根据不同日期（例如价值日期与交易日期）获得余额。
• 逆转/取消是一种乐趣。想象一下，从两周前撤销交易，仍然保持上述所有目标。

你知道，这是一个很长的故事。但是，您的问题的答案是：是的，您无法累积越来越多的交易，您需要保留中间余额以限制数量，以便在需要时累积。点击主表有限数量的行，应该没有问题。

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

Answer 2

执行面向对象的设计，为对象创建表格示例帐户，交易等。这里有一个很好的website供您参考。但在网上讨论OODBMS还有很多。当我开始做OODBMS时，我给出的参考仅仅是我的基础。