4

我对正确的 SQL 解决方案有疑问。

当前情况：我的数据库包含带有银行交易（贷记和借记）的表。

  • 信用交易被签署为正数（+），并且
  • 借记交易为负金额 (-)。

使用数据库的应用程序是一个多用户 webapp，因此事务表包含许多行，它们引用不同的用户。一些 webapp 操作需要检查登录用户的实际余额，使用 Transactions 表并保存借记 Transaction（操作价格）。

我想到了这个机制的架构，有一些疑问：

  1. 每次用户请求时将余额计算为交易贷方和借方的总和是一个好主意吗？我知道这对 db 可能效率低下。也许我应该在某处保存快照？

  2. 当一个用户检查“余额”作为贷记/借记交易的总和，而另一个用户同时保存借记交易（因为他/她更快）时，如何确保数据凝聚力？我想到了一个悲观的锁，但我应该锁什么？我知道在 Postgresql（我使用的数据库）上可能无法使用聚合锁定 (SUM)。”

对不起我的英语，我希望我的问题是可以理解的。:)

4

2 回答 2

1

如果您想避免在用户帐户上出现余额，那么可能会有更好的性能，我会尝试的方法是：

  • 每笔交易将仅与一个帐户相关。
  • 每笔交易在该交易之后都会有账户余额。

因此，该帐户的最后一笔交易将具有当前余额。

前任。：

TransactionId | AccountId | Datetime | Ammount | Balance 
            1 |         1 | 7/11/16  |       0 |       0 
            2 |         1 | 7/11/16  |     500 |     500 
            3 |         1 | 7/11/16  |     -20 |     480 
            4 |         1 | 8/11/16  |      50 |     530 
            5 |         1 | 8/11/16  |    -200 |     330

通过这种方式，您将能够获得账户余额（与该 accountId 的最后一笔交易），并且您将能够更好地查看余额随时间的变化。

于 2016-11-07T17:38:18.177 回答
1

我会考虑：

在帐户记录中存储余额以及余额准确的日期。

获取当前余额是读取账户余额，然后包括自该日期以来的所有交易。

您可以有一个计划作业，该作业重新计算并在午夜后一小时平衡时间戳。

或者（这是我的首选解决方案）：

每次加载一个事务或一批事务时，锁定相关的帐户记录并使用插入的值更新它们作为同一事务的一部分。

这具有序列化对帐户的访问的优势，然后可以帮助确定交易是否可以继续，因为基于余额计算的决策。

于 2016-11-07T17:01:13.017 回答