ms的Best Practices Analyzer Tool for Microsoft SQL Server 2000 1.0上个月发布了1.0版本，和beta版相比，看起来没有什么太大的变化。Best Practices Analyzer Tool for Microsoft SQL Server 2000检查的一些rules可以做为t-sql编程的checklist
sql server数据库编程指导以及最佳实践
原则
编写高可读的代码：遵循命名原则和代码风格约定
开始就要关注t-sql代码性能的影响：减少网络流量，减少磁盘IO，利用索引，避免lock
编写安全的代码
------------------------------------------------------------------------------
命名数据库对象时，采用统一的前缀或者后缀
采用统一的前缀或者后缀是为了提高代码的可读性，但是
存储过程不要使用sp_作为前缀，函数不要使用fn_作为前缀。
如果sql server发现存储过程以sp_作为前缀，都会先到master数据库中查询这个存储过程
添加必要的注释
存储过程或者函数，视图前应该注释创建者, 创建时间，修改者，修改时间，功能注释，使用说明，同时包含一到多条执行该对象的语句
及时检查执行状况
默认情况下，如果一条sql语句执行错误，sql server不会自动roll back前面的执行（可以设置：SET XACT_ABORT ON），sql语句执行完毕后，需要及时通过全局变量@@error和@@rowcount来检查执行状况。
用标准的join方式
标准的join方式是指while语句中只包含过滤条件，不包含join条件
尽量避免客户端程序直接通过select,insert,update等直接操作数据库
用存储过程封装数据访问，存储过程是经过编译的，不用每次计算execute plan。而且封装了逻辑，同时增加了安全性。
存储过程如果需要返回数据，使用output关键字
不要用return返回数据，存储过程的return应该返回存储过程的执行状况，如果需要返回数据，使用带有output关键字的参数
谨慎使用IDENTITY作为表的主键的数据类型
IDENTITY会给客户端程序和database交互带来很多影响，而且在数据导入导出时也会带来麻烦，需要仔细评估这些影响。但是IDENTITY和guid相比也有优点，就是可读性。
尽量避免使用NULL
如果没有特别设置，null参与的运算结果都为null，如果疏忽这一原则，会对程序逻辑的正确性带来影响，而且，客户端程序需要额外的步骤来处理NULL。需要设置ANSI_NULLS为ON。
在insert语句中，使用确定的列名
insert语句中，使用确定的列名以间少表结构变化对t-sql代码带来的影响
尽量使用外键，约束检查来保证数据的完整性
数据完整性至关重要，外键，约束检查可以避免另外写代码来保证数据完整性
不要在查询时用select * ，用确定的列名来代替 *
查询结果中冗余的信息影响整体的性能
尽量避免使用服务器端游标
服务器端游标对性能有严重的影响，应当尽量避免，比如可以用while循环来代替游标，如果不能避免，则应选择最合适的游标类型
尽量避免使用临时表
临时表会发生磁盘IO操作，影响性能，可以用嵌套查询，view，或者table变量来代替临时表。如果需要缓存大量的数据，临时表优于table变量，同时注意为临时表建index
如果需要执行一系列sql命令，在前面添加SET NOCOUNT ON
执行SET NOCOUNT ON，sql命令执行影响的行数不会传回客户端，减少网络流量，提高性能
在字符串匹配查询时，避免在第一个字符位置使用通配符
如果第一个字符位置使用通配符，则index不起作用
避免使用IN 或者NOT IN
使用IN 或者NOT IN，则index不起作用
事务处理时，尽可能的占用最少的资源
事务处理时，尽可能的占用最少的资源以减少资源的锁定，提高数据库整体性能。同时检查加锁类型，尽量使用低级别的加锁类型。
匹配的事务处理
如果存储过程开始了事务处理，应该负责结束这个事物处理，submit或者rollback
操作NCHAR或者NVARCHAR数据类型的列时，使用N关键字
使用N关键字，sql server会使用unicode编码，避免出现乱码
尽量避免使用TEXT,NTEXT,binary,image数据类型的字段，尽量避免将文件或者图片直接存入数据库
这些数据类型访问方式不同于普通的数据类型。数据库也不是存储文件或者图片内容合适的地方
尽量使用VARCHAR代替CHAR，用NVARCHAR代替VARCHAR，
用VARCHAR代替CHAR是为了节省数据库空间，NVARCHAR代替VARCHAR是为了避免unicode带来的麻烦
如果某个table中的数据对不同用户的可见性是不一样的，使用view来隔离用户对table的直接访问
检查sql注入式攻击对代码的影响。
打印 | 张贴于 2004-07-01 13:57:00 | Tag:Dot Net
留言反馈
煩請高手多多指教…
全網站使用unicode，並且，輸入多國語系時並沒有相關的問題發生。
只有在輸入大量的"雙位元字"的時候，寫入資料庫會將所有文字變成"??????"，難到是因為分揀配對錯誤就會產生配對錯誤?
還是跟word的編碼會有有關係呢?
一般来说，我们要求所有的存储文字的地方用unicode，因为我们要支持韩文，日文，繁体，简体。
>>数据库未必不适合存储文件或者图片，虽然访问blob确实和普通数据类型有差异，连Documentum都支持用数据库存放文件。
嗯，这一点Best Practices不够严谨，顺便提一点，我们把html存入数据库，比如<a>abc</a>de，在查询abcde时因为<a>之类格式标示的影响，得不到正确结果，不知道有没有什么好办法。
>>就算是like '%keyword%'，index也可能会起作用的
虽然like'keyword%'肯定比'%keyword%'快
只是可能会起影响，为了简化起见，统一限制第一个字符位置使用通配符
如果第一个字符位置使用通配符，则index不起作用
使用IN 或者NOT IN，则index不起作用
就算是like '%keyword%'，index也可能会起作用的
虽然like'keyword%'肯定比'%keyword%'快
使用Unicode不是很有必要，一般的项目不必要支持多种unicode字符，只是使用中英文不必用Unicode
数据库未必不适合存储文件或者图片，虽然访问blob确实和普通数据类型有差异，连Documentum都支持用数据库存放文件。