问SQL中的查询设计实践

EN

回答这个问题的人不是从访问的角度来回答这个问题的，所以我将作为自1996年以来一直在专业地创建访问应用程序的人提供一些观察结果。

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

VBA

• 存储窗体、报表、组合框和列表框的queries.

• stored属性。代码中的

1. ，您可以在其中动态编写

。

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

首先，考虑存储的查询。如果您遵循这样的建议，即为每个单独的任务保存一个查询，以便每个SQL语句只在一个地方使用，那么您很快就会在查询列表中弄得一团糟，并且您将被迫使用某种命名约定来跟踪什么是什么。正因为如此，我通常不会保存查询，除非它们必须保存，或者保存的查询的优化是有用的(例如，大型数据集或复杂的连接/过滤)。

例如，当我第一次开始在Access中编程时，我会将组合框的所有行源保存为已保存的查询。我开发了一个命名约定，这样它们就不会与查询列表中的其他查询混在一起，所以管理起来并不困难。起初，我以为我会重用保存的查询，但很快就明白了，我需要针对个别情况进行更改，并且更改其他地方使用的查询可能会在其他上下文中更改其结果，所以实际上，保存的查询没有“共享代码”的好处(正如我认为的那样)。唯一有帮助的地方是我在多个窗体上有相同的组合框，然后我可以将它的行源保存为已保存的查询，如果我需要更改它，我可以只在一个位置进行更改。然而，这实际上只是相对复杂的行源的一个优点--对几个字段的简单选择并不能真正从这种共享中受益，特别是当它只在几个不同的地方使用时。

简而言之，我很快得出结论，在使用SQL语句的地方保存它们更容易--因为最初几乎没有重用(一旦我获得了足够的经验来认识到尝试重用它们的陷阱)，这种方法工作得更好，并且它使SQL接近使用它的位置。

对于窗体和报表，我做了一些相同的事情，但一般来说，使用保存的查询是为了避免编写太多复杂的子选择作为派生表。在我需要的地方，编写它并保存它，然后在另一个SQL语句中与连接一起使用它总是比尝试使用subselect内联作为派生表更容易(这只会造成难以阅读的复杂SQL --特别是当您无法注释或格式化SQL时，就像保存的Access查询一样)。

一般来说，我不会保存窗体或报表的记录源，除非有真正的重用正在进行(报表通常会使用与窗体相同的记录源，因此在这种情况下，保存它很有用，这样当您更改窗体的SQL时，与之配套的报表将继承所做的更改)。

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

我不知道这是否真的回答了您的问题，但多年来我了解到，由于无法轻松跟踪SQL语句的使用位置而带来的不确定性，大大超过了重用SQL语句的好处。我发现尽可能靠近使用SQL语句的地方存储SQL语句是最佳实践，因为这是一种“自文档”形式(虽然不是很好！)。

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

我的浅见是，无论DB引擎是像MSSQL或Oracle那样庞大和庞大，还是像SQLite一样微小和简单，每个查询(或存储过程或任何其他数据处理单元)都应该只负责一个函数。我在任何地方都使用这个原则(不仅仅是在DB开发中)，我可以说它是有效的。如果您不确定，请尝试阅读有关重构的书籍，例如Fawler。我认为他的原则适用于任何开发领域。

如果您将数据存储在MSAccess中，那么您的数据库就不能太大，并且您所做的任何优化都会受到MSAccess施加的约束的限制。如果更好(更优化)的查询是一个目标，那么也许将数据从Access迁移到SQL Server可能会让您在以后的开发中拥有更好的灵活性。您可以利用缓存的执行计划、存储过程和视图。这可能意味着您将需要提高您的T-SQL技能来完成此任务。

因此，权衡你在问题中提出的选项: 1.保持代码简单(适合你目前的技能水平) 2.履行为数据提取创建高效查询的责任。

SQL Server Express可能是一个很好的起点(它是免费的)。