为报告处理大量 COUNT 查询答案

【问题标题】：Handling lots of COUNT queries for a report为报告处理大量 COUNT 查询
【发布时间】：2011-06-17 00:41:54
【问题描述】：

我正在整理一份报告，其中显示了拥有这些产品的公司的产品统计信息。该报告以我需要的形式包含多达 150 个“计数”，因为我们在表格中填写了针对 15 个不同统计类别的 12 种产品类型的计数。

这是模型的设置。恐怕有点复杂！

Company is the entity accessing the report.

Company has many Products through Matchings; and  
Product has many Companies through Matchings.

Matching belongs_to Order.

Example report:
___________|_Available/Active/Light   Available/Active/Heavy   (+12 columns)__
Perishable |
Intangible |
(+10 rows) |

产品类型在产品表中（它们在报告的左侧向下排列）。报告顶部的类别是三个标准的组合：两个来自产品，一个来自订单。

示例 - 对于 Perishable 行中的一个单元格，显示订单类型为“活动”、产品重量为“轻”且产品状态为“可用”的匹配项'。

就其本身而言，上述查询并不算太糟糕，但如果我继续这样下去，我将对这份报告进行约 170 次查询——这既是一个不雅且非常不切实际的解决方案。有没有神奇的 ActiveRecord 方法来处理这种情况？

【问题讨论】：

我认为这不是可以通过一些“分组”魔法来解决的问题，并将平面结果重新格式化为网格？
@MarcB - 我想可能是这样，但我不知道如何让它正常工作 - 几个小时的实验并没有显示出足够的改进。此外，我之前在让 group_by 在 MySQL 和 PostgreSQL 上工作时遇到了问题。
是否可以在连接模型中创建一些自定义计数器缓存？有关示例/灵感，请参阅此答案：stackoverflow.com/questions/978779/…

标签： ruby-on-rails ruby-on-rails-3 activerecord

【解决方案1】：

您始终可以创建一个后台作业以定期运行并预先缓存结果，或预先生成整个报告。这将使您的用户不必坐下来等待 170 个查询运行，而且我认为结果稍微陈旧是可以接受的。

至于它的优雅和实用性，您唯一可以使用的魔法就是 SQL。您的对象模型不是为报告而构建的，不要为使用这样的工具而感到难过。

【讨论】：

【解决方案2】：

有一个statistics gem 可以做这种事情。它确实允许您缓存统计信息。

我将它用于计数和平均值等轻量级统计数据，但从未进行过基准测试，如果性能是一个问题，这绝对是something you'll want to do。

【讨论】：