SQL Server查询设计：避免10个错误
前十个列表
1、数据模型和并发查询
如果你在构建数据模型的时候没有考虑到数据的访问方式，将会导致难以处理的查询。你可能会用到根本不必要的JOIN增加代码，损害性能。
要纠正这个问题，考虑一下需要访问数据的查询。如果查询在这个处理阶段不是很清晰，那么将来在写代码的时候就会更困难。很有可能是数据库设计过于复杂，可以通过简化来改善查询的性能。
与此相关，如果你是个喜欢直观的人，那么就打印出数据模型，或者在你选择数据建模工具的时候查看一下在线的模型。这可以改善你的代码时间和精确性。
2、什么是最好的技巧?
这就是声名狼藉的指针与基于集合的逻辑讨论。传统的至理名言说，对所有的数据库访问都使用基于集合的逻辑。一般来说，我同意这是最好的经验之一。当基于集合的逻辑是正确的选择的时候，却使用了指针，可能会对性能产生很大的损害。SQL Server的设计是使用基于集合的逻辑，并且在大多数处理中应该使用它。
事分两面，另一面就是指针的例子。在这种情况下，指针逻辑胜过基于集合的逻辑。从这个信息引申出来的结论就是，判断你要执行的处理的类型，选择最适合需要的技巧。
3、以原有的方式……
SQL Server 2005为你的查询提供了一整套新的机会。所以使用老的办法可能仍然会起作用，但是也是时候去考虑一下最新的选择了。TRY…CATCH错误处理方法是你最先应该使用在代码中的技巧之一。此外还要考虑的是对层次进行处理的时候，可以用到通用表压缩;最后一项考虑是扩展关系型数据库引擎的功能:通用语言运行时(CLR)。这三项技术都在极大程度上改变了你使用SQL Server工作的方式，而它们只是冰山一角。
4、你还让一只笨鹅在那里吗?
检查你的代码，然后安排一个时间进行同样的查看，这是在部署代码之前必须要做的事情。检查你的代码，明确查询计划，是确保使用了合适的索引，并且查询会像你期望的那样运行的重要保障。
5、这是经典错误
输入SELECT *语句，想着表永远不会改变，这是一个经典的查询设计错误。即使在最简单的解决方案中，表的改变也是不可避免的，你需要查看代码确保没有包含一个额外的字段。或者，更糟糕的是，你必须等待应用程序崩溃，然后修正这些问题。最好的实践方案只是在你的查询中包含进来你需要的那些字段，然后必要的话就修改它们。不要把你的时间浪费在四处冒烟的模式中彻查代码。