1、MIS 系统课程设计规范（草案）1开发环境规范使用 windows 操作系统使用 SQL Server 或 ACCESS 数据库2开发语言规范使用团队熟悉的一种开发语言，如：VB,Delphi,ASP,JSP,Java3开发文档的规范需求文档规范设计文档规范程序编码标准附录：数据库编码标准9.1 大小写规则1. 关键字采用大写。2. 系统定义的对象及数据类型采用小写。3. 引用变量、参数、列名，以及表、过程和视图之类的对象名时，使用混合的大小写9.2 缩进与空白1. 选择a.一般缩进为两个英文字符的宽度，但 SELECT 语句的折行显示应字段对齐，例如：SELECT CustomerID,Co
2、mpanyname,ContactName,ContactTitle,Address,City,Region,PostalCode,Country,Phone,Fax,FROM Northwind.dbo.customersb.没有理由将一个短的 SELECT 语句拆为多行。例如： IF EXISTS（SELEC * FROM Northwind.dbo.Customers）c.对于比较长的 SELECT 语句，通常将每个主要子句放置在单独的一行中，并且让它们左对齐。通常将列紧挨 SELECT 保留字之右放置。如果存在许多列而无法放置在同一行中，则只要在下一行中继续给出此列表，通常对位于第二行
3、和后续行中的列缩进排列，以便它们与第一行中的列对齐。例如：SELECT CustomerID,Companyname,ContactName,ContactTitle,Address,City,Region,PostalCode,Country,Phone,Fax,FROM Northwind.dbo.customersWHERE City IN(London,Madred)2. 字句与谓词a.构成主要子句的较小子句让它们相互对齐, 如果将一个复合句的组成部分放置在同一行中，则通常用圆括号分隔它们。例如：SELECT CustomerID,CompanyName,ContactName,Con
4、tactTitle,Address,City, Region,PostalCode,Phone,Fax,FROM Northwind.dbo.CustomersWHERE City = ChinaOR City = London OR City = Madrid 3. 表达式如果一个 CASE 表达式比较简单，则我通常将其嵌入单一的代码行。如果它比较复杂，则将其拆为多行。对于函数及其他类型表达式也如此，例如：SELECT CustomedD，CompanyName，ContactName,ContactTitle，Phone， CASE WHEN Fax Is NULL THEN N ELSE
5、 Y END ASFaxFROM Northwind.dbo.CustomersWHERE City = London较复杂的 CASE 表达式通常占用多行SELECT CASE RegionWHEN WA THEN PhilWHEN SP THEN XavierWHEN BC THENJ Jean-MarcELSE UnknownEND AS Salesman，CustomerID,CompanyName,ContactName,FROM Northwind.dbo.CustomersORDER BY Salesman9.3BEGIN/END规则参照 DELPHI 编码标准 2.3。9.4
6、圆括号规则参照 DELPHI 编码标准 3.1。9.5 水平间隔规则参照 DELPHI 编码标准 2.5。9.6 列与表的别名对于列与表的别名通常使用的是 ColumnName As Label, 建议表的别名用一个或两个缩写字符。在 SELECT 列表中的列名前应用各自的表别名作为列引用的前缀，其理由有两个。第一，它增加了代码的可读性。不必猜测一个列是源自哪里。第二，它增强了代码的健壮性。如果您在此后向查询中增加一个表，该表恰巧包含一个与未限定的列同名的列，则将得到令人讨厌的“不确定的列名”错误消息。9.7 缩写与可选关键字1. 关键字对于可选关键字。一般应在自己的代码中省略它们。这种代码决
7、不会产生语法错误，决不会中断，决不会通过对工具的修改而变得失效，而且不占用宝贵的屏幕资源。其中的例外就是与 INSERT 命令一起的 INTO 关键字不要省略，因为在 ORACLE 数据库中必须这样，以及与 DELETE 命令一起的 FROM 关键字要省略。2. 常见单词的缩写当您在自己创建的对象名中缩写常见单词时，请尽量保持一致。如果在一个名称中将number 缩写为“ Num”，则在所有对象中都做类似的缩写。不要在一个表中缩写为“ No” （如，CustNo） ，而在另一个表中又缩写为“ Number” （如，InvoiceNumber） 。请保持一致。9.8 名称选择当命名一个对象时，要
8、避免表、视图、UDF、过程、触发器、默认值和规则对象之间的命名冲突，因为它们的命名必须唯一。例如，不能让一个存储过程和一个表拥有相同的名称。如前所述，尽量保持命名的描述性，而不放任自流。1. 表对于表，通常应使用单个单词的单数形式的实体类型名称（如，Customer） 。如果表与其它表有关联，应尽量建立主键与外键。2. 视图对于视图，通常应使用 V_开头，加上有意义的描述性单词（如，V_Customer） 。3. 索引索引命名应据用描述性，见名知意，如果一个索引是建立在表 Customer 的CompanyName 和 ContractName 列之上，则好的命名应为 CompanyNameC
9、ontractName 或类似的名称，因为索引不必在整个数据库中唯一，这样只看一下名称就可以知道该索引的主键是什么。4. 触发器对于触发器，使用这样一种命名规则，它表示激发触发器的动作和该触发器所关联的表名（如，DeleteCustomer 或 InsertUpdateOrder） 。如果触发器拥有特别的特性 (如，它是一个 INSTEADOF 触发器)，则通常通过一个名称的前缀来表明这一点（如，InsteadOfDeleteCustomer） 。建议：除非别无它法，否则应尽可能避免使用触发器。5. 变量参照 DELPHI 编码标准 3.4。 6. 过程和函数过程与函数应以基于动词的形式命名，
10、如 PostPurchases 或 BuildHistory。7. 约束约束的命名应能区分是哪一各类型的约束，并能根据名称知道该约束是干什么的，通常主键前加前缀 PK_，外部键加前缀 FK_，唯一键加前缀 UK_，检查约束加前缀 CK_，如：PK_EmployeeID，CK_Amount must not equal 0。建议：如果表中的某列或多列不可以出现重复记录，应尽可能地在这此列上建立唯一约束。9.9 编码约定1. 脚本建议(1) 对象删除试图删除一个对象之前应检查其存在性。不这样做会不必要地生成错误消息，甚至当DROP 命令被分割在其自己的 TSQL 批处理之中。错误消息应该是一种会引
11、起您注意的内容，而不是一种可以经常被忽略的内容。应避免生成不必要的错误消息，以免变得对它们熟视无睹。(2) 注释通过平衡澄清含糊与不确定的编码元素的需求与让代码免于噪声和不必要干扰的需求，来确定在自己的代码中“注释”什么。过分的注释与注释不足同样不可取。过分注释一个脚本将给您带来大量的工作，还不能真正改善代码的可读性。当处理某些从编码的角度来看不是显而易见的，并且那些继续处理此编码的人应该知道的内容时，才应注释它。任何有意义的存储过程都应该在其开始处包含一个代码块，用来描述该过程以及该过程做什么。如同对待任何源代码过程，跟踪诸如谁修改了代码和修改代码的时间等事项也可以是非常方便的注释应尽量用斜
12、线-星号(/*/)，而少用双斜线(/)(3) 脚本文件一般而言在一个单独的脚本文件中保存自己所创建的每个数据库对象的源代码。对于重新创建或修改对象而言，这样做提供了最大的灵活性。(4) 脚本段如果脚本包含多个没有共享局部变量的不同段，那么通常用 GO 来分隔各个段，以便模块化所要执行的操作。按照这种方式，如果在其中一个段出现错误，则可以防止它引起紧跟其后的段出错。相反地，如果希望脚本段只在其前一个脚本段不出错的条件下执行，则可以去掉 GO 并将两块代码合并为一块。如果在前面的块中出现较严重的错误，则位于后面的块中的命令永远都不会执行。(5) USE如果一个脚本必须从给定数据库中运行，那么在脚本
13、中尽可能地包含合适的 USE 命令。2. 存储过程与函数(1) 变量声明如果可能，应集中地在一个位置声明存储过程或函数将使用的变量，最好在过程或函数的开始处。尽管语法上允许在代码的任何位置声明变量，但为查找一个变量声明而不得不搜索一个例程将浪费时间并导致代码更难于理解。(2) 存储过程的返回值与参数在存储过程中对于过程的返回值应检查其正确性并做出适当的处理，通常，值 0 表示成功，非零值表示已出现了错误，对于存储过程的参数，应尽早检查参数的正确性，并且当提供的值不对时应返回一个错误，这样防止无效值或操作影响数据的正确性。(3) 默认参数值给存储过和或 UDF 的参数提供默认值是一种不错的做法，
14、这让它们更易于使用、更灵活和更不易出错。(4) 错误健壮代码的标志在于全面的错误检查，应在关键操作和相应响应之后进行错误检查。通常在可能导致一个错误条件的语句这后立即检查ERROR ，并且当一个语句没有影响任何构成错误的行时，检查ROWCOUNT 。(5) 模块性较之于单一且非常长的存储过程，一组较小且逻辑简单的例程更易于处理和理解。在可能的情况下，应将复杂例程拆分为较小的例程。3. 表与视图(1) 临时表在可能的情况下，应尽量过分使用临时表。两个理由：第一，它们可以导致吞吐量问题，因为位于 tempdb 的资源争用。第二，与永久表相比，对于保持对临时表的更新统计，SQL Server 更为主
15、动。这会引起性能问题和未预料的存储过程的重编译。避免临时表的一种策略是使用 table 变量，当它超出作用域时，会被自动删除。(2) 资源清除在使用监临时表时，应在不再需要时删除它们。对于游标也是如此：当使用完它们，应关闭并释放它们。(3) 系统表除非别无它法，应力求避免直接查询系统表，SQL SERVER 提供一组属性函数（如，DATABASEPROPERTY()、COLUMNPROPERTY()、OBJECTPROPERTY()等）以及大量视图与系统存储过程供您使用，直接查询系统表有两点不足。第一，系统表在不同版本之间会有变化。第二，与等价的属性可无数据函数相比，通过直接引用系统表获得的系
16、统级信息通常欠缺可读性。4. Trabsact-Sql (1) 特殊了一 SQL在可能的情况下，应避免通过 EXEC（）函数执行特殊 TSQL。有两个理由。第一，由特殊 TSQL 生成的执行计划不能像存储过程的执行计划那样得以重用。第二，特殊TSQL 非常难于调试。 因此，如果可能，应将代码放置在正常的存储过程和函数等对象之中，然后调用这些对象。这几乎总是优于任何动态 TSQL 途径。如果必须执行在运行时生成的 T-SQL，则我力求使用扩展过程 sp_executesql。它通常明显快于 EXEC（） ，而且服务于 sp_executesql的执行计划被插入缓存并可被复用。(2) COMPUTE 与 PRINTCOMPUTE 是一个坏消息，因为它实际上导致多结果集被创建。您必须对它们全部做迭代，以便获得由一个 COMPUTE 查询所返回的所有行。ROLLUP 和 CUBE 运算符更好，因为它们可以完成 COMPUTE 所完成的全部操作，甚至更多，但是，它们这样做时不需要额外的结果集。PRINT 也欠理想，ADO 不能正确地返回报告消息，除非还正好产生一个包含大于 10 的严重级的消息。换言之，当使用 ADO 运行查询时，将永远不会看到 PAINT 消息，除非还产生了此查询的真正错误消息。
