sql - 聚合还是不聚合，这是数据库模式设计的问题

Question

如果您正在执行最小/最大/平均查询，您更喜欢使用聚合表还是简单地查询原始表中的一系列行？

这显然是一个非常开放的问题，没有一个正确的答案，所以我只是在寻找人们的一般建议。假设原始数据表由时间戳、数字外键(例如用户 ID)和十进制值(例如购买金额)组成。此外，假设表中有数百万行。

我两者都做过，但很受打击。一方面，聚合表给了我显着更快的查询速度，但代价是增加了额外的表。显示聚合范围的当前值需要完全返回原始数据表或组合更细粒度的聚合。我发现在应用程序代码中跟踪查询哪个聚合表的时间比您认为的更多，并且需要更改架构，因为原始聚合范围总是不够的(“但我想看看我们在过去 3 个支付期内的销售额!”)。

另一方面，从原始数据查询可能会非常缓慢，但让我对数据范围非常灵活。当范围边界发生变化时，我只需更改查询，而不必重建聚合表。同样，应用程序代码需要较少的更新。我怀疑如果我对我的索引更聪明(即始终拥有良好的覆盖索引)，我将能够减少从原始数据中进行选择的惩罚，但这绝不是 Elixir 。

无论如何，我可以拥有两全其美的吗？

Answer 1

我们遇到了同样的问题并遇到了您遇到的相同问题。我们最终将报告切换到 Analysis Services。 MDX 和分析服务本身有一个学习曲线，但它很棒。我们发现的一些好处是:

你有很大的灵活性
以您想要的任何方式查询。在我们之前
必须建立特定的聚合体，
但现在一个立方体回答了我们所有的问题
问题。

立方体中的存储空间要小得多
比详细数据。

构建和处理立方体
花费更少的时间和更少的生产
数据库服务器上的负载比
总量做到了。

一些缺点:

周围有一个学习曲线
构建多维数据集并学习 MDX。

我们必须创建一些工具来
自动处理多维数据集。

更新:
由于您使用的是 MySql，您可以查看 Pentaho Mondrian ，这是一个支持MySql的开源OLAP解决方案。不过我从来没有用过，所以我不知道它是否适合你。有兴趣知道它是否适合你。