Microsoft Access 中 CTE 的替代方案答案

【问题标题】：Alternatives to CTEs in Microsoft AccessMicrosoft Access 中 CTE 的替代方案
【发布时间】：2016-05-06 20:10:24
【问题描述】：

我每天都在使用 MS Access 2010，我想知道 SQL Server 中使用的通用表表达式是否有替代品，以及它如何影响性能？

例如，创建子查询更好还是从另一个查询中调用查询更好，这本质上非常相似..

例子：

SELECT A.field1,A.Date
FROM (SELECT * FROM TABLE B WHERE B.Date = Restriction )

或

SELECT A.field1,A.Date
FROM SavedQueryB

SavedQueryB：

SELECT * FROM TABLE B WHERE B.Date = Restriction

我觉得有多个查询更容易调试和管理，但是当数据集非常大时它会影响性能吗？

另外，我看过一些关于通过 VBA 实现查询的视频，但是我还不太习惯这样做。

基本上。 什么是更有效或更好的做法？对更好的做法有何建议或建议？ 我主要是通过视频、书籍和一些编程背景（VB.NET）自学的

【问题讨论】：

标签： vba ms-access database-design subquery ms-access-2010

【解决方案1】：

对于最简单的查询，例如您的问题中的查询，我怀疑您会发现子查询和“堆叠查询”（使用另一个保存的查询作为其数据源）方法之间存在显着的性能差异。也许数据库引擎甚至会为两者使用相同的查询计划。（有兴趣可以使用SHOWPLAN查看查询计划。）

这两个示例的主要性能驱动因素是数据库引擎是否可以使用索引检索来获取满足WHERE 限制的行。如果TABLE.Date 未编入索引，则查询将需要全表扫描。对于非常大的数据集，这会很糟糕，并且完全扫描对性能的影响应该远远超过子查询和堆叠查询之间的任何差异。

对于Allen Browne explains这样的复杂子查询，情况可能会有所不同：

对包含许多记录的表执行复杂的子查询可能运行缓慢。

在子查询性能问题的潜在修复中，他建议...

使用堆叠查询而不是子查询。创建一个单独的保存查询 JET 首先执行，并将其用作输入“表” 您的主要查询。这种预处理通常（但不总是）比子查询快。同样，尝试一次执行聚合查询，然后创建另一个对聚合进行操作的查询结果。这种后处理可以比尝试在带有子查询的单个查询中完成所有操作的查询。

我认为您的最佳答案将来自测试更复杂的现实世界示例。您问题中的查询非常简单，因此从中得出的结论可能不适用于那些现实世界的查询。

【讨论】：

【解决方案2】：

这实际上取决于上下文，因为许多场景将决定最有效的结果，包括数据类型、连接表、索引等。本质上，对于像张贴SELECT statmeents 这样的简单查询，这两个查询是等效的，但是Jet/ACE（MS Access 的底层引擎）查询优化器可能会根据查询的结构需要再次决定不同的计划。可能，调用外部查询会在执行计划中添加一个步骤，但随后子查询可以作为自包含表执行，然后链接到主表。

回想一下 SQL 的一般操作顺序，它不同于输入顺序，因为每个步骤都涉及一个虚拟表（请参阅SQL Server）：

FROM clause       --VT1
ON clause         --VT2
WHERE clause      --VT3
GROUP BY clause   --VT4
HAVING clause     --VT5
SELECT clause     --VT6
ORDER BY clause   --VT7

可以说，对于存储的查询对象，MS Access 会分析并缓存优化后的“最佳计划”版本。这通常是使用存储查询而不是 VBA 字符串查询的论点，后者在执行之前没有优化。更进一步，Access 的 query 对象类似于其他 RDMS 的 view 对象（尽管 Jet/ACE 确实有 VIEW 和 PROCEDURE 对象）。 SQL 世界中的定期讨论涉及您的效率和最佳实践问题：views vs subqueries，通常答案会返回“视情况而定”。因此，根据需要进行实验。

这里的 CTE 被认为是由 WITH 子句表示的“内联视图”（JET/ACE 尚不支持）。 SQL 程序员可以使用 CTE 来提高可读性和可维护性，因为您可以避免在语句体中多次引用同一语句。总而言之，使用适合您的编码习惯和项目要求的内容，然后根据需要进行调整。

资源

MS Access 2007 Query Performance Tips - 附注子查询性能
Intermediate Microsoft Jet SQL - 关于子查询的注释（刚刚了解了ANY/SOME/ALL）
Microsoft Jet 3.5 Performance White Paper - 附上查询计划的注释

【讨论】：

非常感谢！这正是我一直在寻找的信息，而且您的解释很简单，很难找到它！非常感谢！

【解决方案3】：

我不记得在哪里，但有关于嵌套或子查询这个主题的讨论。基本上他们都建议保存的查询，然后引用保存的查询。

从个人经验来看，嵌套查询很难在以后进行故障排除或修改。此外，如果他们变得太深，我会遇到性能下降。

Allen Browne 列出了几个技巧和窍门 here

我经常使用嵌套查询的一个地方是动作查询的标准。这样我就没有任何连接，可以限制一些“无法执行此操作”的问题。

最后，在 VBA 中使用查询字符串。我发现构建参数查询然后在 VBA 中为 QueryDef 设置一个变量并添加参数比在 VBA 中构建查询字符串要容易得多。以后更容易排除故障和修改。

只要我的两分钱。

【讨论】：