SQL中的查询设计实践

Question

我正在建立MS Access
2007中数据库的查询，并且想知道我当前的设计实践是否达到标准。基本上，数据库是在我来之前配置的，但是我被赋予构建高效查询以提取数据的责任。

我当前的查询既小又简单，每个查询一次完成2-3个任务（有时只有1个）。之所以采用这种方法，是因为我对SQL完全陌生，并且发现与许多简单的查询一起使用并使用报告来合并数据比较容易，而与构建极其复杂的查询相对较容易，后者非常难于进行：1）难以构建（无论如何对我而言）和2）难以维护。

我只是想知道是否有人具有查询设计的最佳实践，是否可以为我提供上述方法的特定反馈，以及是否应该开始进行复杂的查询，还是只坚持简单的查询和报告呢？合并相关数据。

谢谢。

Answer 1

从Access的角度来看，回答这个问题的人们并不是来回答这个问题，因此，从1996年以来，我一直在从事全职专业的Access应用程序开发工作，因此我将提供一些意见。

首先，在Access应用程序中有几个地方可以使用SQL：

1. 存储的查询。

2. 表单，报表，组合框和列表框的存储属性。

3. 在您正在动态编写SQL的VBA代码中。

即使不是不可能，以有组织的方式管理所有这些SQL语句也很困难。但是我不确定是否值得！

首先，请考虑仅存储查询。如果您遵循为每个任务保存查询的建议，以使每个SQL语句仅在一个地方使用，那么查询列表很快就会变得一团糟，并且您将被迫采用某种命名约定跟踪什么是什么。因此，除了必须将查询保存在哪里，或者保存的查询附带的优化将对您有所帮助（即大型数据集或复杂的联接/过滤）之外，我通常不保存查询。

例如，当我第一次开始在Access中编程时，我会将组合框的所有行源都保存为已保存的查询。我开发了一个命名约定，因此它们不会与查询列表中的其他查询混在一起，因此管理起来并不难。起初，我以为我会重用已保存的查询，但是很快就很清楚，我需要针对个别情况进行更改，并且更改在其他地方使用的查询可能会在其他情况下更改其结果，因此保存的查询没有“共享代码”的好处（就像我想的那样）。唯一有用的地方是我在多个表单上具有相同的组合框，然后可以将其行源保存为已保存的查询，并且如果需要更改它，则可以在一个地方进行。然而，

简而言之，我很快得出结论，将SQL语句保存在使用它们的位置上会更容易-
因为首先很少进行重用（一旦我获得了足够的经验，就可以体会到尝试重用的陷阱）它们），效果更好，并且使SQL接近使用位置。

对于表单和报表，我做一些相同的事情，但是总的来说，使用保存的查询是为了避免不得不写太多复杂的子选择以用作派生表。在需要这些代码的地方，编写它并保存它，然后在另一个SQL语句中将其与JOIN一起使用总是比尝试将subselect内联用作派生表要容易得多（这使得难于阅读的复杂SQL变得更容易了）
-尤其是当您无法注释或格式化SQL时（如已保存的Access查询的情况）。

通常，除了真正进行重用的地方，我不会保存表单或报表的记录源（报表通常会使用与表单相同的记录源，因此在这种情况下，保存它很有用，这样当您更改表单的SQL时，它所伴随的报表将继承更改。

所有这些都将动态SQL组装在VBA代码中。从动态设置组合/列表框的行源到设置子窗体的记录源以进行过滤，我使用了很多这样的方法。这很难管理，有时我在模块中使用字符串常量使之更容易。例如，在编写动态SQL的情况下，除了WHERE子句外，其他所有东西都保持不变，带有SELECT的常量和带有ORDER
BY的第二个常量使组装完整的SQL语句变得容易得多。

我不知道这是否真的回答了您的问题，但是多年来我了解到，重用SQL语句的好处远远超过了无法轻松跟踪该SQL语句的使用位置所带来的不确定性。我发现最好将SQL语句存储在尽可能靠近它的位置，因为这是一种“自我文档”形式（尽管不是很好！）。

当确实在性能或管理方面有真正的明显好处时，我确实会做很多例外，并保存查询，否则将使SQL变得更加复杂。但是，我还要指出的是，使用大量嵌套的已保存查询，也不应在另一个方向上走得太远，因为这样会遇到其他问题（即“数据库过多”问题，这实际上是由于使用一次最多提供2048个表句柄-
比您想象的要容易得多）。