如何以编程方式快速构建即席查询？

Question

我已经使用Excel数据透视表来分析来自我的数据库的数据，因为它允许我非常快速地“切片和切块”。由于我们知道数据库表中的内容，因此我们都可以编写SQL查询来完成数据透视表的功能。

但我想知道为什么数据透视表能够如此快速地构建查询，同时它知道什么都没有关于数据和我们给它的数据字段之间的含义/关系？

用另一种方式提出问题，我们如何才能以这种快速高效的方式构建专用 SQL查询？ （当然是“使用数据透视表！”，但是，我想要的是一种编程方式）。

Answer 1

根据需要操作您的订单和组条款。

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

Answer 2

我直观的感觉告诉我，答案必须是与数据透视表的轮廓，其中有一个固定多个区域，分别是：

- 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. 

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

Answer 3

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

为什么速度更快，有一个重要的非算法可能性：数据透视表使用中的Excel没有连接的概念。从数据库中提取特定数据时，表之间的任何连接或关联都会导致进一步的查找，扫描，索引加载等。由于Excel将所有数据都放在一个位置（RAM或不是），因此它可以执行查找而不必预先形成数据集。如果您要将数据库数据加载到临时表中，那么查看针对该表的临时查询如何针对Excel以性能方式进行堆叠会很有趣。

但有一件事是确定的：虽然数据库是生成准确报告的绝佳工具，但传统规范化的数据库对于即席查询来说远不是最优的。因为规范化的数据结构集中在完整性高于一切（如果我可以采取这种自由），他们牺牲特别优化而牺牲所有数据的合理性。虽然这是一个坏榜样，考虑这个归一化模式：

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

SELECT * FROM luGenders; 
> 1 Female 
> 2 Male 

如果，在这个例子中，我们想知道，在我们的系统中的女性/男性用户的数量，该数据库将需要处理连接和行为（同样，由于联接数量少和可能值数量少，这通常会导致一些数据库引擎优化，所以这是一个不好的例子）。但是，如果您要将这些数据转储到Excel中，您仍然会因数据库处罚而拖延数据，但实际上在Excel中转​​移数据的速度相当快。这可能是因为你的Excel比直接临时查询更快，但是我没有数据发表评论，所以错过了这种前期固定成本惩罚的概念。

尽管最切题的一点是，尽管一般数据库对准确性有好处，但他们经常会在特别报告中感到厌倦。为了生成临时报告，通常有必要在更可查询的结构中对数据进行反规范化（“仓库”）。查询关于数据仓库的信息将为这个主题提供很多好的结果。道德故事：拥有一个完全算法的快速临时查询系统是一个非常理想的选择，但是由于空间和时间的限制（内存和人员小时数），这个系统并不适合实际。为了有效地生成临时系统，您需要了解数据的使用情况，然后有效地对其进行非规范化。我会强烈推荐The Data Warehouse Toolkit。为了记录，我不是DBA，我只是一个低级分析师，每周花费80个小时的时间来处理Excel和Oracle。我知道你的痛苦。