我使用Excel PivotTable来分析数据库中的数据，因为它使我可以非常快速地"切片和切块"。正如我们知道数据库表中的内容一样，我们所有人都可以编写执行PivotTable所做的SQL查询。

但是我想知道为什么PivotTable可以如此快速地构造查询，而对数据以及我们提供的数据字段之间的含义/关系一无所知？

用另一种方式提出问题，我们如何以这种快速有效的方式构建临时SQL查询？ (是的，"当然，请使用数据透视表！"，但是我想要的是一种编程方式)。

解决方案

回答

只需根据需要操纵order和group子句。

Excel之所以快速，是因为所有数据都在内存中，并且可以快速高效地对其进行排序。

回答

我的直觉告诉我答案与"数据透视表"轮廓有关，该轮廓具有固定的区域数，即：

- the Page Fields zone  
- the Column Fields zone  
- the Row Fields zone and
- the Data zone

在我的疯狂猜测中：

- The Page zone builds the WHERE part of the ad-hoc query.  
- The Column zone will put whichever fields drag-dropped to it in the GROUP BY clause.  
- The Row zone will build a SELECT DISTINCT <field names>
- The Data zone will apply an AGGREGATE function to the field drag-dropped to it.

当我们将字段拖到这些区域时，我们认为"幕后"会发生什么？

回答

@Mark Ransom绝对具有Excel的概念，可以将数据保留在内存中，从而使计算速度更快。 Excel还可能以一种比数据库更具响应性的方式对数据集进行预索引。

为什么它更快，有一种重要的，非算法的可能性：Excel在数据透视表的使用中没有联接的概念。当我们从数据库中临时获取数据时，表之间的任何联接或者关联都会导致进一步的查找，扫描，索引加载等。由于Excel将所有数据都放在一个位置(RAM或者否)，因此执行查询而无需预先形成数据集。如果要将数据库数据加载到临时表中，那么看看该表中的即席查询如何以性能为依据，如何以Excel为基础进行堆积会很有趣。

不过，可以肯定的是：尽管数据库是生成准确报告的出色工具，但是传统上规范化的数据库远不是临时查询的最佳选择。因为规范化的数据结构将重点放在完整性之上(如果我愿意考虑的话)，所以它们牺牲了临时优化，却以保持所有数据合理为代价。尽管这是一个糟糕的示例，但请考虑以下标准化模式：

+--------+     +---------+
|tblUsers|     |luGenders|
+--------+     +---------+
|userID  |     |genderID |
|genderID||gender   |
+--------+     +---------+

SELECT * FROM luGenders;
> 1 Female
> 2 Male

如果在此示例中，我们希望知道系统中的女性/男性用户数量，那么数据库将需要处理联接并相应地执行操作(同样，由于联接数量少且数目低，所以这是一个不好的示例可能的值，通常应该带来一些数据库引擎优化)。但是，如果要将这些数据转储到Excel，则仍然会产生一些数据库损失以提取数据，但是实际上在Excel中旋转数据将相当快。Excel比直接特殊查询要快的想法可能错过了预先固定成本罚款的概念，但是我没有数据要评论。

不过，最切线的是，尽管通用数据库具有较高的准确性，但它们经常会占用临时报告。为了生成临时报告，通常需要以更可查询的结构对数据进行规范化("仓库")。查找有关数据仓库的信息将在该主题上提供很多良好的结果。

故事的寓意：拥有一个完整的算法，快速的即席查询系统是一个了不起的理想，但在给定的时间和空间限制(内存和工时)的情况下，它比实际要少。为了有效地生成临时系统，我们确实需要了解数据的用例，然后对其进行有效地规范化。

我强烈建议我们使用"数据仓库工具包"。作为记录，我不是DBA，我只是一个卑微的分析师，每周花费80个小时来浪费Excel和Oracle。我知道你的痛苦