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

Question

我正在设计一个数据库，用于保存交易级别的数据。它将像银行账户一样工作——对账号进行借方/贷方操作。

如何最好/最有效地获取这些交易的聚合？我考虑使用汇总表，然后将其添加到今天的交易清单中，以便推导出每个帐户拥有的金额（即其余额）。

我希望这可以扩展（例如10亿笔交易），因此不想对主要事实表执行数据库访问，因为它需要查找所有与所需帐户号码关联的借方/贷方，并可能扫描10亿个行。

谢谢您的帮助和资源。

- Jimmyn

Answer 1

（在银行工作了将近10年。以下是实际操作方法）

简而言之：你的想法很好。

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

“当前”余额没有保存在任何地方。仅仅为了避免更新此余额时可能出现的锁定问题。 （在真正的银行中，您将使用几乎每个单独交易的某些银行内部账户。有许多银行内部账户可以满足法律要求的数字。这些账户经常被访问，因此如果您想对每个交易进行更新，则会导致锁定问题。相反，每个交易都只是插入 - 即使结转余额也只是插入）。

此外，在真正的银行中，您有许多用例使得此方法更为有利：

• 随时能够获取以往的余额 - 能够基于不同的日期随时获取余额（例如价值日期与交易日期）。
• 撤销/取消也是一种乐趣。想象一下从两周前开始撤销交易，但仍保持上述所有操作。

您看，这是一个漫长的故事。但是，回答您的问题是：是的，您无法累积越来越多的交易，您需要保留中间余额以限制可能需要累积的数量。对于有限数量的行访问主表不应该成为问题。

确保您的主查询使用仅索引扫描。

- Markus Winand

---

谢谢您的回答。您的回答非常有道理，我也认为有类似的过程。关于如何从“结转余额”表格和最近交易清单中获取余额，您是否可以使用union all将它们合并，然后对合并后的数据集应用聚合以获取个人的余额。感谢您的帮助。 - Jimmyn

Answer 2

进行面向对象设计，创建对象表，例如Account、Transaction等。这里有一个网站可以供您参考。但是网络上还有很多关于OODBMS的讨论。我提供的参考只是我开始做OODBMS的基础。

- JC Borlagdan