文档介绍：数据库编码标准
对齐。例如：
SELECT CustomerID,Companyname,ContactName,ContactTitle,Address,City,
Region,PostalCode名称就可以知道该索引的主键是什么。
触发器
对于触发器，使用这样一种命名规则，它表示激发触发器的动作和该触发器所关联的表名（如，DeleteCustomer或InsertUpdateOrder）。如果触发器拥有特别的特性(如，它是一个INSTEADOF触发器)，则通常通过一个名称的前缀来表明这一点（如，InsteadOfDeleteCustomer）。建议：除非别无它法，否则应尽可能避免使用触发器。
变量
。
过程和函数
过程与函数应以基于动词的形式命名，如PostPurch
ases或BuildHistory。
约束
约束的命名应能区分是哪一各类型的约束，并能根据名称知道该约束是干什么的，通常主键前加前缀PK_，外部键加前缀FK_，唯一键加前缀UK_，检查约束加前缀CK_，如：PK_EmployeeID，CK_Amount must not equal 0。建议：如果表中的某列或多列不可以出现重复记录，应尽可能地在这此列上建立唯一约束。

脚本建议
对象删除
试图删除一个对象之前应检查其存在性。不这样做会不必要地生成错误消息，甚至当DROP命令被分割在其自己的T－SQL批处理之中。错误消息应该是一种会引起您注意的内容，而不是一种可以经常被忽略的内容。应避免生成不必要的错误消息，以免变得对它们熟视无睹。
注释
通过平衡澄清含糊与不确定的编码元素的需求与让代码免于噪声和不必要干扰的需求，来确定在自己的代码中
“注释”什么。过分的注释与注释不足同样不可取。过分注释一个脚本将给您带来大量的工作，还不能真正改善代码的可读性。
当处理某些从编码的角度来看不是显而易见的，并且那些继续处理此编码的人应该知道的内容时，才应注释它。任何有意义的存储过程都应该在其开始处包含一个代码块，用来描述该过程以及该过程做什么。如同对待任何源代码过程，跟踪诸如谁修改了代码和修改代码的时间等事项也可以是非常方便的
注释应尽量用斜线-星号(/*…..*/)，而少用双斜线(//)
脚本文件
一般而言在一个单独的脚本文件中保存自己所创建的每个数据库对象的源代码。对于重新创建或修改对象而言，这样做提供了最大的灵活性。
脚本段
如果脚本包含多个没有共享局部变量的不同段，那么通常用GO来分隔各个段，以便模块化所要执行的操作。按照这种方式，如果在其中一个段出现错误，则可以防止它引起紧跟其后的段出错。相反地，如果希望脚本段只在其前一个脚本段不出错的条件下执行，则可以去掉GO并将两块代码合并为一块。如果在前面的块中出现较严重的错误，则位于后面的块中的命令永远都不会执行。
USE
如果一个脚本必须从给定数据库中运行，那么在脚本中尽可能地包含合适的USE命令。
存储过程与函数
变量声明
如果可能，应集中地在一个位置声明存储过程或函数将使用的变量，最好在过程或函数的开始处。尽管语法上允许在代码的任何位置声明变量，但为查找一个变量声明而不得不搜索一个例程将浪费时间并导致代码更难于理解。
存储过程的返回值与参数
在存储过程中对于过程的返回值应检查其正确性并做出适当的处理，通常，值0表示成功，非零值表示已出现了错误，对于存储过程的参数，应尽早检查参数的正确性，并且当提供的值不对时应返回一个错误，这样防止无效值或操作影响数据的正确性。
默认参数值
给存储过和或UDF的参数提供默认值是一种不错的做法，这让它们更易于使用、更灵活和更不易出错。
错误
健壮代码的标志在于全面的错误检查，应在关键操作和相应响应之后进行错误检查。通常在可能导致一个错误条件的语句这后立即检查@***@ERROR，并且当一个语句没有影响任何构成错误的行时，检查@***@ROWCOUNT。
模块性
较之于单一且非常长的存储过程，一组较小且逻辑简单的例程更易于处理和理解。在可能的情况下，应将复杂例程拆分为较小的例程。
表与视图
临时表
在可能的情况下，应尽量过分使用临时表。两个理由：第一，它们可以导致吞吐量问题，因为位于tempdb的资源争用。第二，与永久表相比，对于保持对临时表的更新统计，SQL Server更为主动。这会引起性能问题和未预料的存储过程的重编译。避免临时表的一种策略是使用table变量，当它超出作用域时，会被自动删除。
资源清除
在使用监临时表时，应在不再需要时删除它们。对于游标也是如此：当使用完它们，应关闭并释放它们。
系统表