【问题标题】:What is the best practice database design for transactions aggregation?事务聚合的最佳实践数据库设计是什么?
【发布时间】:2016-04-08 03:31:28
【问题描述】:

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

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

我正在考虑使用汇总表,然后将其添加到今天的交易列表中,以得出每个帐户的余额(即余额)。

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

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

【问题讨论】:

    标签: sql database


    【解决方案1】:

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

    TLDR:你的想法不错。

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

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

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

    • 能够随时取回过时的余额 - 能够随时获取基于不同日期的余额(例如起息日与交易日)。
    • 撤销/取消是它自己的乐趣。想象一下,从两周前撤消一笔交易,仍然保持上述所有操作。

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

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

    【讨论】:

    • 感谢您的回答。你的回答很有意义,我认为有一个类似的过程。在从“结转余额”表和最近交易列表中获取余额方面,您是否只需使用一个联合将它们放在一起,而不是对组合集应用聚合以获得个人余额。感谢您的帮助
    【解决方案2】:

    进行面向对象的设计,为对象创建表,例如帐户、交易等。这里有一个很好的website 供您参考。但是网上还有很多关于 OODBMS 的讨论。我提供的参考资料只是我开始做 OODBMS 时的基础。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-11-11
      • 2010-10-30
      • 2011-11-23
      • 2015-07-20
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多