提问者:小点点

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


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

获取这些交易聚合的最佳/最有效方式是什么。

我在考虑使用全量表,然后将这些添加到今天的交易列表中,以便得出每个账户有多少(即他们的余额)。

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

谢谢,任何帮助或资源将是真棒。


共2个答案

匿名用户

(已经在银行工作了将近10年。以下是它是如何实际完成的)。

TLDR:你的主意不错。

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

“当前”余额没有保存在任何地方。如果你一直更新这个余额,你会遇到锁定问题。(在真实的银行中,几乎每笔交易都会触及一些银行内部账户。有很多银行内部账户能够获得法律要求的数字。这些账户经常被击中,因此当你想在每笔交易中更新它们时,会导致锁定问题。相反,每笔交易都只是插入——甚至结转余额也只是插入)。

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

  • 能够随时取回日期余额-能够随时获得基于不同日期的余额(例如价值日期与交易日期)。
  • 撤销/取消本身就很有趣。想象一下,从两周前撤销一笔交易,但仍保持上述所有操作。

你看,这是一个很长的故事。然而,你的问题的答案是:是的,你不能积累越来越多的交易,你需要保留中间余额来限制在需要时积累的数量。命中主表的行数有限,应该没有问题。

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

匿名用户

做一个面向对象的设计,为对象创建表,例如帐户、事务等。这是一个很好的网站供您参考。但是网上有很多关于OODBMS的讨论。我给的参考只是我开始做OODBMS的基础。