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

我当前的查询很小，很简单，每次只完成2-3个任务（有时只有1个）。我之所以采用这种方法，是因为我对SQL完全陌生，我发现处理许多简单的查询和使用报表来整合数据更容易，而不是构建非常复杂的查询，这些查询1）很难构建（对我来说，无论如何）2）很难维护

我只是想知道是否有人拥有查询设计的最佳实践，您是否可以就上面列出的方法向我提供一些具体的反馈，以及我是否应该开始进行复杂的查询，还是只使用简单的查询和报告来整合相关数据

---

谢谢。

我的拙见是，不管DB引擎是像MSSQL或Oracle那样大而可怕，还是像SQLite那样小而简单，每个查询（或存储过程或任何其他数据处理单元）都应该只负责一个函数。我在任何地方都使用这个原则（不仅仅是在DB开发中），我可以说它是有效的。

---

如果您不确定，请尝试阅读有关重构的书籍，例如Fawler。我认为他的原则适用于任何开发领域。

如果您将数据存储在MSAccess中，那么您的数据库不能太大，您所做的任何优化都会受到MSAccess施加的约束的限制。如果更好（更优化）的查询是一个目标，那么将数据从Access迁移到SQL Server可能会使您在未来的开发中具有更好的灵活性。您可以利用缓存的执行计划、存储过程和视图。 这可能意味着您需要提高您的T-SQL技能来实现这一点

因此，请权衡您在问题中提出的选项： 1.保持代码简单（以您当前的技能水平为准） 2.履行为数据提取创建高效查询的职责

---

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

回答这个问题的人并不是从访问的角度来看这个问题的，因此我将作为自1996年以来一直专职创建Access应用程序的人提供一些观察

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

存储查询

表单、报表、组合框和列表框的存储属性

在VBA代码中，您正在动态编写SQL

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

首先，只考虑存储的查询。如果您按照建议为每个任务保存一个查询，以便每个SQL语句只在一个位置使用，那么很快查询列表中就会出现混乱，您将被迫使用某种命名约定来跟踪内容。因此，我通常不保存查询，除非它们必须保存，或者保存的查询附带的优化会有帮助（即，大型数据集或复杂的连接/过滤）

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

简言之，我很快得出结论，将SQL语句保存在使用它们的地方更容易——因为一开始很少有重复使用（一旦我获得足够的经验，认识到尝试重复使用它们的陷阱），这样做效果更好，并且使SQL与使用它的地方保持距离

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

一般来说，我不会保存表单或报表的记录源，除非有真正的重复使用（报表通常会使用与表单相同的记录源，因此在这种情况下，保存它很有用，这样当您更改表单的SQL时，随附的报表会继承更改）

所有这些都让动态SQL组装在VBA代码中。从动态设置组合框/列表框的行源到设置子窗体的记录源以进行过滤，我使用了很多方法。这很难管理，有时我在模块中使用字符串常量来简化管理。例如，在编写动态SQL时，除了