要聚合还是不聚合，那就是数据库模式设计问题

如果您正在执行min/max/avg查询，那么您更喜欢使用聚合表还是仅查询原始表中的一系列行？要聚合还是不聚合，那就是数据库模式设计问题

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

我已经完成并且被撕裂了。一方面，聚合表为我提供了更快的查询速度，但代价是增加了额外的表。显示聚合范围的当前值要么完全返回到原始数据表或组合更多细粒度聚合。我发现在应用程序代码中追踪哪个聚合表要查询何时需要更多的工作，并且需要更改模式，因为原始聚合范围总是不够用（“但我想看看我们在过去3个薪酬阶段的销售额！“）。

另一方面，从原始数据查询可能会受到惩罚，但让我对数据范围非常灵活。当范围边界发生变化时，我只需更改查询而不必重新生成聚合表。同样，应用程序代码也需要更少的更新。我怀疑如果我的索引更聪明（即总是有很好的覆盖索引），我可以减少从原始数据中选择的惩罚，但这决不是万能药。

无论如何我能拥有两全其美？

来源

2009-12-23 pr1001

这是干什么用的数据库？ – 2009-12-23 23:33:55

我通常使用MySQL，但希望人们的提示适用于所有SQL数据库。 – pr1001 2009-12-23 23:46:15

@ pr1001：这在一定程度上是一个普遍问题，但是一些数据库提供了使这个问题更容易的机制（例如Oracle的“物化视图”），所以这样做“正确”将会是数据库特定的程度 – skaffman 2009-12-24 10:41:44

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

对于您有很多灵活性，可以以任何您想要的方式查询。在我们必须建立特定聚合之前，但现在一个多维数据集回答了我们所有的问题。
存储在一个立方体中比详细数据要小得多。
建筑及处理花费较少的时间和比聚集体确实产生了数据库服务器上较少负载的立方体。

一些缺点：

周围有建筑多维数据集和学习MDX一个学习曲线。
我们必须创建一些工具来自动处理立方体。

UPDATE：既然你使用MySQL，你可以看看Pentaho Mondrian，这是支持MySQL的开源OLAP解决方案。我从来没有使用它，所以我不知道它是否会为你工作。有兴趣知道它是否适合你。

来源

2009-12-23 23:36:21 jvilalta

+ 1提到Pentaho。一些参与Pentaho的人来自BI的Cognos名声。 – cethegeek 2009-12-24 14:38:06

我总是倾向于原始数据。一旦汇总，你不能回去。
与删除无关 - 除非有最简单的聚合数据集，否则无法准确地将数据恢复/转置回原始数据。

理想情况下，我会使用物化视图（假设数据可以适应约束），因为它实际上是一个表。但是MySQL不支持它们，所以下一个考虑因素是计算列的视图或更新实际表的触发器。

来源

2009-12-24 00:42:44

我是否错过他建议聚合和删除原始数据的部分？当然，原始数据需要保留。但除了原始数据之外，一些汇总数据也可以存储。 – marcc 2009-12-24 00:46:22

@marcc：我在哪里说原始数据会被删除？ – 2009-12-24 01:02:16

@Ponies：也许当你说，一旦汇总，你不能回去:) – 2009-12-24 11:13:53

它有助于选择一个好的主键（即[user_id，used_date，used_time]）。对于一个常量user_id，在used_date上做一个范围条件非常快。

但随着表的增长，您可以通过聚合到像[user_id，used_date]这样的表来缩小表的大小。对于时间不重要的每个范围，您可以使用该表格。另一种缩小表格大小的方法是归档您不再（允许）查询的旧数据。

来源

2009-12-24 10:36:00 Menno

要聚合还是不聚合，那就是数据库模式设计问题

回答

相关问题