数据库设计：计算账户余额

Question

如何设计数据库来计算账户余额？

1）目前我从交易表计算账户余额 在我的交易表中，我有“描述”和“金额”等。

然后，我将添加所有“金额”值，这将计算出用户的帐户余额。

---

我向我的朋友展示了这个，他说这不是一个好的解决方案，当我的数据库增长时，它会变慢？？？他说我应该创建单独的表来存储计算出的帐户余额。如果这样做，我将不得不维护两个表，并且有风险，帐户余额表可能会不同步。

有什么建议吗？

编辑：选项2：我应该在交易表“余额”中添加一个额外的列吗？ 现在我不需要遍历许多行数据来执行计算。

例子 约翰购买了 100 美元的信贷，他借了 60 美元，然后他增加了 200 美元的信贷。

金额 100 美元，余额 100 美元。

金额 - 60 美元，余额 40 美元。

金额 200 美元，余额 240 美元。

Answer 1

这是一个从未得到优雅解决的古老问题。

我使用过的所有银行软件包都将余额存储在帐户实体中。根据运动历史即时计算它是不可想象的。

正确的做法是：

• 机芯工作台有一个‘开口’
  每个账户的余额交易。你需要
  几年后当你
  需要将旧的机芯移出
  活动运动表到历史记录
  桌子。
• 账户实体有余额
  场上
• 有动作触发
  更新帐户的表
  贷方和借方账户的余额。显然，它有承诺
  控制。如果你没有触发器，那么就需要一个独特模块来在承诺控制下写入动作
• 你有一个“安全网”程序
  可以离线运行，重新计算
  所有天平和显示屏（以及
  （可选地更正）错误的
  余额。这对于
  测试。

某些系统将所有移动存储为正数，并通过反转“起始”/“终止”字段或使用标志来表示贷方/借方。就我个人而言，我更喜欢贷方字段、借方字段和签名金额，这使得冲销更容易遵循。

请注意，这些方法同时适用于现金和证券。

证券交易可能会更加棘手，特别是对于公司行为，您将需要适应一项更新一个或多个买方和卖方现金余额、其证券头寸余额以及可能的经纪人/存款人的交易。

Answer 2

这是我得到的数据库设计，只有一个表用于存储操作/事务的历史记录。目前正在许多小型项目中发挥魅力。

这不会取代特定的设计。这是一个通用的解决方案，可以适合大多数应用程序。

id：整数
标准行 ID

operation_type:int
操作类型。支付、收取、利息等

source_type：int
从操作进行的地方。
目标表或类别：用户、银行、提供商等

source_id：int
数据库中源的 id

target_type:int
操作所应用的内容。
目标表或类别：用户、银行、提供商等

target_id:int
数据库中目标的 id

金额:decimal(19,2signed)
价格值正数或负数相加

account_balance:decimal(19,2signed)
生成的余额

extra_value_a:decimal(19,2signed) [这是不使用字符串存储的最通用的选项]
您可以存储额外的数字：利息百分比、折扣、减少等。

created_at:timestamp

对于 source_type 和 target_type，最好使用枚举或表格设备。

如果您想要特定的余额，您可以只查询按created_at降序限制到1排序的最后一个操作。您可以按源、目标、操作类型等查询。

为了获得更好的性能，建议将当前余额存储在所需的目标对象中。

Answer 3

您应该存储当前帐户余额并始终保持最新状态。交易表只是过去发生的事情的记录，不应该仅仅为了获取当前余额而高频率使用。考虑到许多查询不仅仅需要余额，它们还希望根据余额进行过滤、排序和分组等。在复杂查询中对您创建的每笔交易进行求和所带来的性能损失甚至会削弱适度大小的数据库。

对这对表的所有更新都应该在一个事务中，并且应该确保所有内容保持同步（并且帐户永远不会透支超过其限制）或事务回滚。作为一项额外措施，您可以运行审核查询来定期检查这一点。

Answer 4

当然，您需要将当前余额存储在每一行中，否则速度太慢。为了简化开发，您可以使用约束，这样您就不需要触发器和定期检查数据完整性。我在这里描述了反规范化以强制执行业务规则：运行总计

Answer 5

此问题的常见解决方案是在快照模式中维护（例如）每月期初余额。可以通过将当月的交易数据添加到每月期初余额来计算当前余额。这种方法通常在帐户包中采用，特别是在可能需要货币兑换和重估的情况下。

如果您遇到数据量问题，您可以归档旧余额。

此外，如果您的系统上没有专用的外部数据仓库或管理报告工具，则余额对于报告也很有用。

Answer 6

你的朋友错了，你是对的，我建议你现在不要改变事情。
如果您的数据库因此而变慢，并且在验证了所有其余部分（正确的索引）之后，可能会使用一些非规范化。
然后，您可以将 BalanceAtStartOfYear 字段放入“帐户”表中，并仅汇总今年的记录（或任何类似的方法）。
但我肯定不会预先推荐这种方法。

Answer 7

这里建议您如何以非常简单的方式存储期初余额：-

1. 在事务表上创建一个触发器函数，仅在更新或插入后调用。

2. 在帐户主表中创建一个名为“期初余额”的列。

3. 将您的期初余额保存在主表的期初余额列的数组中。

4. 你甚至不需要使用服务器端语言，使用这个存储数组，你可以使用数据库数组函数，比如 PostgreSQL 中提供的函数。

5. 当您想重新计算数组中的期初余额时，只需将您的交易表与数组函数分组并更新主表中的全部数据。

我已经在 PostgreSQL 中完成了这个并且工作正常。

当您的事务表变得很重时，您可以根据日期对事务表进行分区以加快性能。
这种方法非常简单，不需要使用任何额外的表，因为连接表时会降低性能，因为连接中的表越少，性能就越高。

Answer 8

我的方法是将借方存储在借方列中，将贷方存储在贷方列中，并在获取数据时创建两个数组，即借方和贷方数组。然后继续将选定的数据追加到数组中，并为 python 执行此操作：

def real_insert(arr, index, value):
    try:
        arr[index] = value
    except IndexError:
        arr.insert(index, value)


def add_array(args=[], index=0):
    total = 0
    if index:
        for a in args[: index]:
            total += a
    else:
        for a in args:
            total += a
    return total

然后

for n in range(0, len(array), 1):
    self.store.clear()
    self.store.append([str(array[n][4])])
    real_insert(self.row_id, n, array[n][0])
    real_insert(self.debit_array, n, array[n][7])
    real_insert(self.credit_array, n, array[n][8])
    if self.category in ["Assets", "Expenses"]:
        balance = add_array(self.debit_array) - add_array(self.credit_array)
    else:
        balance = add_array(self.credit_array) - add_array(self.debit_array)

Answer 9

实现账户余额的优雅方式是什么？

虽然这是一个老问题，但我发现这个问题反映了数据库设计（甚至更进一步，软件设计）的一些深刻问题。我已经思考这个问题好几年了，所以我在这里写下一些结论。

让我们首先考虑一个简单的链表。您可以添加、删除或修改列表中的元素，还可以检索元素计数。当您添加或删除元素时，应更新元素计数。那么，您认为元素计数应该被存储，还是按需重新计数？

在大多数库的实现中，元素计数是存储的，这是为了性能。但是，这个存储的“属性”永远不会暴露给用户。因此，用户不知道 count 属性是根据需要存储还是重新计算，他们只是通过 length() 或 size( ) 方法，并相信它返回的计数始终是最新的。

这正是我们想要的一种实现账户余额的优雅方式。这里概括了要点：

1. 用户不必手动输入余额，它们是自动计算的。
2. 从高层设计的一个方面来看，数据库设计者将帐户余额视为它们是“派生的”。设计师不会费心考虑何时更新余额。
3. 从底层实现的角度来看，账户余额的实现方式是始终保持最新、需要时重新计算，并且仍然具有良好的性能。

这就是分层设计和封装的哲学。我在这里描述了它：

现在，重点是如何实现“balances”层。如果它是使用带有 SUM 函数的普通 SQL 视图定义来实现的，那么我们知道会出现性能损失，从而损害扩展。

近年来 SQL 出现了一些新功能，可以减轻这种性能损失。例如：窗口函数。我在此处描述了一个带有窗口函数的解决方案。

但这还不够，即使计算余额的时间复杂度是 O(n)，我们也希望将其降低到 O(1)，因为它的使用频率很高。

因此，唯一的方法是存储（更准确地说，缓存）余额以便快速访问。并且，在需要时，增量更新。即不是将所有交易从零开始求和，而是根据刚刚变化的内容进行计算。

目前，有几种方法可以处理这个问题：

1. 使用触发器。
2. 使用存储过程。
3. 使用命令式编程语言（如Python、C++）自定义更新余额的逻辑。

这些方法都不够方便或可靠。例如，如果使用触发器，如何确保存储余额的表永远不会被某人意外修改？我们需要将该表指定为“始终由触发器更新，而不是由人工更新”。 SQL对此没有限制。

我希望将来会出现一个真正优雅的 SQL 工具，也许像“自定义视图”之类的东西，允许程序员自定义该视图更新或存储的方式和时间。但现在，至少我们知道了分层设计的哲学。因此，我为自己的簿记系统这样做：

目前，使用 SQL 视图来计算余额（借助窗口函数），并使这一层足够独立。将来，如果性能损失被证明是无法承受的，或者出现更优雅的方式，请用新的工具替换该层。这将更换平衡层的影响降至最低。

Answer 10

简单的答案：三个都做。

存储当前余额；并在每笔交易中存储该时间点的变动和当前余额的快照。这将在任何审计中提供额外的协调。

我从未从事过核心银行系统的工作，但我从事过投资管理系统的工作，根据我的经验，这就是它的工作原理。