作为一个使用sqlserver的项目leader,你第一需要知道的是“sqlerver能做什么，不能作什么”。也许数据迁移，也许你遇到数据优化问题不

知道该怎么做，或者您仅仅想知道使用sqlserver的进行数据访问层的设计指南。这篇文章适合你。
即使你没有使用sqlserver,绝大多数设计指南也适用其它数据库管理系统。对程序员来说sybase是一个很熟悉的环境，oracle也能从中受益。

我并不想显示具体的使用t-sql技巧，也对你的问题给不了神奇的解决方案。这里并没有完成，或解决的问题。我只想从多年的教训中学来的经

验给你一些好的设计建议。发现一遍又一遍出现的设计错误。

1.了解你的工具

请不要低估这个建议，它是所有建议中最好的。你惊讶的发现多少程序员并不知道tsql所有的命令和sqlserver都又那些有效的工具。
“什么？我要花费一个月的时间学习一些将来不用的命令？”你可能说no,你不需要。但花费一个周末时间在msdn。浏览所有的tsql命令：它能

说什么，不能做什么。在未来，当你设计一个查询时候，你将记得：“嘿，有个命令能有效完成我们所需要的”。然后你在去参考msdn查看它

的准确语法。
在这里我假定你以及了解了T-SQL语法或者你能在MSDN上找到它。

2.不要使用游标

再次提醒：不要使用游标。它是扼杀整个系统性能的第一途径。绝大多数初学者使用游标并没有认识到它对性能的伤害。他们使用大量的内存

，以很怪异的方式锁表，而且执行速度巨慢。最可恶的是它让DBA所做的所有优化无效。你知道执行游标和相似的select之间的区别吗？这意味

着如果你的游标又10000条记录，它将执行大约10000次select.如果你单独执行这些select ,update,delete,它将非常块。

初学者感觉游标是一种熟悉，舒服的编码方式，不幸的是它导致低下的性能，sql的目的是找出你需要的，而不是它应该怎么做。

有次我重写一个基于游标的存储过程,替换了一些传统的sql查询,这个表仅10万条记录这个存储过程执行了40分钟，而事实是最差劲的程序员也

能写一个执行10秒钟的存储过程。

如果你正读这篇文章，我需要提醒的是这里没有好的游标使用建议。除了DBA工作的需要，我将不会使用游标。

3.规范化你的表

两个通常的借口是：性能或延迟。你迟早要为延迟付出代价。如果不慢就不要优化，常常我发现程序员反规范化数据库。因为他们说这将慢，

然而常常相反。结果这种设计更慢，DBMS被设计来使用规范化数据库，所以要规范化设计

4.不要使用select *

这个规则执行起来有点难。我承认我常使用它。试着指定你需要的列，他将：
a.减少内存消耗和带宽
b.容易安全设计
c.可以利用查询优化，这样可以从索引中读取所需的列。

5.了解你的数据怎么被访问

强健的索引设计是数据库设计的好方法之一。索引设计常常是很艺术的。每次你在一个表上加一个索引，加快了select,变慢了delete,update.

维护索引需要做很多的事情。如果你给一个表加好几个索引，你很会就会注意到当更新索引时将锁很长时间。所以问题是：这个表在干什么？

读，更新数据？这个问题很巧妙，特别对于update和delete.因为他们常常使用where部分调用一个select，然后才更新表。

6.不要在“性别”列上键索引

只是无用的。让我们理解索引怎么加快表的访问的。你理解索引快速部分。如果我们建立一个索引在sex列，你将只有两部分：男女。那你怎么

优化1000万条记录呢？记住维护索引是很慢的。一直设计你的索引最多稀少的列先，最少稀少的列最后如：Name + Province + Sex.

7.使用事务：

特别是长时间执行的查询。当执行错误时使用事务将挽救你。当操作数据时候，你将很快发现一下可以让存储过程崩溃的异常情况。

8.注意死锁。

如果你访问表以相同的顺序，当执行存储过程或事务时，你很快发现死锁。如果你锁表A接着锁表B，一直锁他们以相同的顺序在所有的存储过程。某天在另外一个存储过程中，如果你偶然锁表b接着锁表A，那么将产生死锁。死锁很难被发现。死锁常是由粗心的设计导致的。

9.不要获取大记录

在技术论坛中常看到这样的提问：“怎么把100000条记录快速填充到组合框中”。这是个错误。你不能也不应该这么做。首先你的用户讨厌在10，000条记录中找它需要的。看来需要一个好的ui设计。因为你给用户最多呈现100到200条记录。

10.使用参数化查询语句

有时我们在技术类论坛常看到这样的问题：“我的查询操作引号等字符时失败。我怎么能避免它呢”。常见的回答是：“用一个双引号替换”。错误的！这仅是一个工作场景，如果遇到另外一个字符时仍旧失败。这将导致严重的安全bug.除了这个，它将破坏SQL Server缓存系统（缓存相似的查询）。学怎么使用参数化查询（在ADO,通过使用Command对象，在ADO.NET使用SqlCommand对象），那么上边的问题就不会出现。

11. 一直测试大数据库

通常我们开小数据量的数据上开发，而终端用户使用大量数据量的数据库。这里有个问题：磁盘时便宜的而性能问题被发现时已经太迟了。

12.不要使用insert导入大量数据

如果不是非常必要，请使用DTS或者BCP工具，这是一个既富有扩展性又快速的解决方案。

13.注意超时：

当查询数据库时，缺省超时常很小15秒或30秒。记住查询报告常比这个常。特别是当数据增长时。

14.不要忽视并发修改

有时两个用户同时修改相同记录。最后一个修改者修改成功，但前一个用户的一些更新却丢失了。检查这种情况也很容易：产生一个时间戳列，当修改时候检查它。如果可能的话合并修改。如果有冲突，则提示用户一些动作。

15.当想详细表插入记录时，不要使用从主表中SELECT max(ID)

这是一个常见错误。当两个用户同时插入数据时将失败。用SCOPE_IDENTITY, IDENT_CURRENT, and @@IDENTITY其中一个。尽可能避免使用@@IDENTITY。因为使用触发器可能产生bug.

16.避免使用可空列

他们使用一个多于的字节在每个可空列。当查询时将产生更多的开销。DAL也更难编码。因为每次使用可空列都需要检查。我并不是说null是邪恶的化身。当空数据是你商业规则的一部分时，我相信他们有好的用法和简化代码。一些空列使用在下列情况：
CustomerName1
CustomerAddress1
CustomerEmail1
CustomerName2
CustomerAddress2
CustomerEmail3
CustomerName1
CustomerAddress2
CustomerEmail3
这是糟糕的。经历避免。请规范化你的，它将更扩展性和快速，减少空列。

17.不要使用TEXT数据类型

除非你为了大数据而使用它。Text数据类型对查询来说不灵活，慢，而且浪费大量的空间。经常varchar处理数据更好。

18.不要使用临时表

除非必要。常使用子查询替换临时表。它常增加开销，当运行于COM+给你带来麻烦。因为它使用数据库连接池而临时表将永远保持。在SQL Server 2000中，表变量可作为可选方案。

19.学会怎么读执行计划

SQL Server分析器是你的朋友。你将学会他们怎么工作的。查看查询，索引怎么影响性能。

20.使用参照完整性

这将为你节省大量时间，定义你所有的键，唯一约束，外键。