查询SQL中的设计实践

Question

我正在为MS Access 2007中的数据库构建查询,我想知道我当前的设计实践是否符合标准.基本上,数据库是在我来之前配置的,但是我被赋予了构建有效查询以提取数据的责任.

我目前的查询很简单,每次只完成2-3项任务(有时只有1项).我采用这种方法的原因是因为我对SQL完全不熟悉,并且我发现使用许多简单查询和使用报表来合并数据更容易,而不是构建极其复杂的查询,这些查询很难构建(对我来说,无论如何)和2)难以维持.

我只是好奇,如果有人有任何查询设计的最佳实践,如果你能给我一些上面列出的方法的特定反馈,以及我是否应该开始进行复杂的查询,或只是坚持简单的查询和报告合并相关数据.

谢谢.

Answer 1

回答这个问题的人并没有从Access的角度来看这个问题,所以我会提供一些观察,因为自1996年以来一直专业创建Access应用程序的人.

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

1. 存储的查询.

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

3. 在VBA代码中,您可以动态编写SQL.

即使不是不可能,也很难以有组织的方式管理所有这些SQL语句.但我不确定这是值得的!

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

例如,当我第一次在Access中开始编程时,我会将组合框的所有行源保存为已保存的查询.我开发了一个命名约定,因此它们不会与查询列表中的其他查询混在一起,因此不难管理.起初,我以为我会重新使用已保存的查询,但很快就会发现我需要针对个别情况进行更改,并且更改在其他地方使用的查询可能会在其他上下文中更改其结果,所以实际上,保存的查询没有"共享代码"的好处(正如我想的那样).它唯一有用的地方是我在多个表单上有相同的组合框,然后我可以将行源保存为已保存的查询,如果我需要更改它,我可以在一个地方.然而,这对于相对复杂的行源来说实际上只是一个优势 - 在几个字段上的简单SELECT并没有真正受益于这种共享,特别是当它仅在几个不同的地方使用时.

简而言之,我很快得出结论,将SQL语句保存在使用它们的地方会更容易 - 因为首先几乎没有重复使用(一旦我获得足够的经验来实现重复使用的陷阱)它们运行得更好,它使SQL保持接近使用的位置.

对于表单和报表,我做了一些相同的事情,但一般来说,使用保存的查询是为了避免编写太多复杂的子选择以用作派生表.当我需要那些它总是更容易把它写并保存,然后在另一个SQL语句中的JOIN使用比它要尝试使用子查询直列作为派生表(这只是使复杂的SQL这是难以阅读 - 特别是当您无法对SQL进行注释或格式化时,就像保存的Access查询一样.

一般情况下,我不保存表格或报告的记录来源,除非有真正的重复使用(报告通常使用相同的记录源作为表格,所以在这种情况下,保存它是有用的,所以当您更改表单的SQL时,与其一起使用的报表将继承更改).

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

我不知道这是否真的能回答你的问题,但多年来我已经了解到,重复使用SQL语句的好处远远超过了无法轻松跟踪SQL语句可能使用的地方所带来的不确定性.我发现尽可能将SQL语句存储在尽可能接近的地方是最佳实践,因为这是一种"自我记录"的形式(虽然不是很好!).

当在性能方面有一个真实且可证明的好处或管理可能会变得更加复杂的SQL时,我会做出许多例外并保存查询.但是,我还要注意,使用大量嵌套保存的查询,也不应该朝另一个方向走得太远,因为那时你会遇到其他问题(即"太多数据库"问题,这实际上是由于使用一次可用2048个表格 - 它比你想象的更容易完成.