从连接表计算运行余额[SQL数据库设计]

Question

假设我有三张桌子

TRANSACTIONS

• 金额
• 日期

记录

• 金额
• 日期

CUSTOM_RECORDS

• 金额
• 日期

（我们只是说还有许多其他字段可以证明这些表的分割是正确的）

要计算运行余额，我有两种方法

-------------方法1 -------------

重读READ，点亮WRITE

每当我们阅读时，只需加入表格，按日期排序并计算运行余额。

PRO

• 写入很简单，只需写入每个表格

CON

• 阅读非常繁重，需要在每次阅读时进行计算。 查询是非常奇怪的（从让我们说1周的时间）并对所有记录进行计算。如果我查询10条记录，则需要对100万条记录进行计算才能知道10条记录的余额。

-------------方法2 -------------

重写WRITE，点亮READ

我有另一张桌子

FINAL_TABLE

• 日期
• 金额
• 运行余额

每当我写作时，我刷新此表并再次计算所有运行余额。

PRO

• 读取很简单，已经计算了运行平衡。
• 在时间段之间查询就像从FINAL_TABLE中提取时间跨度之间的日期一样简单

CON

• 写真的很慢，每次写三个表都意味着刷新整个FINAL_TABLE表！

为什么我不重用最新的运行天平？如果条目是现实生活中按时间顺序的保证，则可能发生这种情况。但是，有时可能会迟到。

目前，我正在使用方法2，每次客户端将行保存/更新到三个表中的任何一个时，服务器会在尝试刷新并计算FINAL_TABLE时冻结。显然，这不是很容易扩展。

方法1在查询方面也不是很可扩展。我必须从一开始就计算出运行余额，以便了解上周的运行平衡。

两种方法的可扩展性都不高。什么是良好的设计，以确保READ和WRITE的可扩展性和相对快速的性能？银行用什么方法来跟踪运行平衡？

Answer 1

这取决于。

假设您有一个类似transaction report的报告，其中会显示帐户的运行余额。如果您想显示实时数据，那么总是method 1会更好。我建议您使用Quirky Update而不是cursors，loops，sub-queries或recursions。

另一方面，如果您不需要实时运行总计，那么您可以使用method 2进行一些自定义。在进行交易时，我不支持更新Final Table。而不是我建议用间隔时间表更新它。根据您的流量或负载，您可以在一段时间后更新运行总计。

实时我不鼓励使用method 2，因为它会使您的交易成本高昂。

为了让你的method 1更快，这里有一些链接。

Calculating Running Total

Quirky Update

Quirky Update Performance

Halloween Protection

Create Table AccBalance
(
    AccountNO PK,
    Balance
)

Create Table AccDateWiseCumBalance
(
    AccountNO PK,
    SystemDate PK,
    Cumulative Balance
)

每个交易将更新第一个表格，保持实时余额，但不保留任何历史记录。

第二个表保持帐户和日期明智的累计余额，将在每天结束时更新。

因此，如果您需要前一个日期累积余额，您将从第二个表中检索数据。

如果您需要最新的当前日期累计余额，您将从当前日期之前的第二个表中检索数据，并从第一个表中检索当前日期数据。