交易和余额

Question

我从事承包公司数据库“sql server”的工作。我不知道计算客户余额帐户的最佳解决方案是什么。

1. 余额表：为余额创建表，为交易创建另一个表。所以我的应用程序将任何交易添加到交易表并根据余额表值计算余额。

2. 使用查询计算余额：所以我将只创建交易表。

注意：每年的记录可能多达 200 万条记录，所以我认为他们需要每年备份它或类似的东西。

有什么新想法或新方法？！

Answer 1

如果我是你，我也会有一个 transactions 表和一个 balances 表。例如，假设您有 1 000 000 个用户。如果用户平均有 20 笔交易，那么从交易表中获取余额将比从余额表中获取余额慢大约 20 倍。另外，有东西总比没有东西好。

所以，我会毫不犹豫地选择创建balances 表。

Answer 2

评论你的两种方式：

1. 如果您的查询比更新多得多（100 次或更多），这是一个很好的解决方案。因此，您添加新交易，重新计算余额并存储它。您可以在一笔交易中完成，但可能会花费大量时间并阻止用户操作。因此，您可以稍后再执行（例如，每分钟/小时/天更新一次余额）。优点：阅读速度快。缺点：余额值和交易总和之间可能存在差异或增加用户操作时间
2. 如果您的更新比读取多得多（例如，具有大量交易的交易系统），这是一个很好的解决方案。更新当前余额可能需要时间并且可能毫无价值，因为另一笔交易已经到来:) 因此，您可以在运行时按需计算余额。优点：总是实际平衡。缺点：计算余额可能需要一些时间。

如您所见，这取决于您的有效负载配置文件（读取或写入）。我建议您从第二个变体开始——它很容易实现，良好的数据库索引可以帮助您非常快速地获得总和（每年 200 万 - 不像看起来那么多）。但是，这取决于你。

Answer 3

当然，您必须在交易表旁边有一个单独的余额表。否则在读平衡期间，随着事务的增加，您的性能将一天比一天慢，并且由于其他用户可能同时锁定事务表以读取余额，因此事务的成本会很高。

Answer 4

这个问题似乎有很多意见，我很想关闭它。

但是，在我所经历的客户拥有“余额”的任何环境中，业务的一个关键部分是了解每个客户的当前余额。这意味着有一个历史交易表、一个当前余额金额，和一个审计流程，以确保两者保持一致。

无论何时更改数据库，都会保持当前余额。 “标准”方法是使用触发器。我首选的方法是将数据更改封装在存储过程中，并在用于修改事务数据的相同过程中具有汇总逻辑。