SQL求和与运行总计

我目前与我的同事在数据库的最佳设计方面存在分歧

我们需要经常从我们的交易数据库中访问用户的总余额，我们可能需要每秒多次访问此信息

他说sql很快，我们需要做的就是

SUM（）

事务。一、 另一方面，相信最终有了足够的用户和一个大型数据库，我们的服务器将花费大部分时间对数据库中的相同记录求和。我的解决方案是有一个单独的表格来记录总数

---

我们谁是对的？

这是数据库非规范化的一个例子。它使代码更加复杂，并引入潜在的不一致性，但查询速度会更快。这是否值得，取决于对性能提升的需求

如果能够正确索引，总和也可能相当快（即足够快）

第三种方法是使用定期重新计算的缓存聚合。如果您不需要实时数据（例如昨天之前的帐户活动，您可以使用今天较小的数据集中的实时数据进行补充），则效果最佳

---

同样，要在快速和简单之间进行权衡（不要忘记，复杂性也会引入bug并增加维护成本）。这不是一种方法是否适用于所有情况的问题。

我不认为一种解决方案适用于所有情况

通过一组好的索引和编写良好的查询，您可以走得更远。我将从实时查询开始，直到您无法查询为止，然后跳到下一个解决方案

从那里，您可以存储所有未更改数据的聚合（例如，从时间开始到上个月），只需查询本月更改的任何数据的总和

---

可以保存聚合表，但要保存多少种不同的聚合？在某些情况下，您必须研究某种多维结构。

写入计算总数的数据需要时间。另外，如果它们很快变得不正确，有什么意义？您试图查询的表集有多大？这是OLTP还是OLAP？设置报告主从关系如何？每个用户的预期事务数是多少？换句话说，平均需要处理多少行才能产生一个和？另外，每个用户插入新事务的频率是多少？我们最初的计划是从实时查询开始，然后跳到下一个解决方案。然而，我们开发的系统越多，转移到另一个解决方案就越不切实际。是的，你的答案很好。我的同事和我将就权衡问题展开辩论。这完全取决于我们的网站有多成功。如果我们成功了，我们的数据库将无限期地增长，我们将每秒对整个数据进行多次求和。