数据库对象命名探讨

简介

编码规范是一个优秀程序员的必备素质，然而，有很多人非常注重程序中变量、方法、类的命名，却忽视了同样重要的数据库对象命名。这篇文章结合许多资料，以及我自己的经验，对数据库对象的命名规则提出了一点建议，希望能为大家提供一些参考。

XML:NAMESPACE PREFIX = O />

基本数据库对象命名

表1.数据库对象命名：

关于命名的约定：

变量(T-SQL编程中声明的变量)、过程(存储过程或触发器等)、实体(表、字段)应该根据他们所代表的实体意义和进程作用来命名。

   还有一个常见的错误就是只使用面向计算机的术语，而不是面向公司业务的术语，比如ProcessRecord就是一个含糊不清的命名，应该使用一个进程业务描述来替换它，比如CompleteOrder.

如果完全根据上一条的要求，那么根据业务描述的过程名可能会变得很冗长，比如下面：

prCountTotalAmountOfMonthlyPayments (计算每月付费的总金额)

prGetParentOrganizationalUnitName (获取上级单位名称)

　　此时则应该考虑使用缩写：

原则1：如果可以在字典里找到一个词的缩写，就用这个做为缩写，比如：Mon(Monday)、Dec(December)

原则2：可以删除单词元音(词首字母除外)和每个单词的重复字母来缩写一个单词。比如：Current = Crnt、Address = Adr、Error = Err、Average = Avg

原则3：不要使用有歧异的缩写(一般是语音上的歧义)。比如b4(before)、xqt(execute)，4tran(Fortran)

表格、字段的命名：

单数表名、字段名还是复数表名、字段名？

可能大家很少会考虑到给表名起单数还是复数，比如，对存储客人信息的表，我们应该起Customer，还是Customers？我主张起单数表名，下面是来自ASP?id=18067">《SQL Server 2000》一段引用：

主张用复数表名的阵营认为：表是由一组记录构成的，所以应当使用复数名词来命名它。他们经常使用的理由是：客户表是客户们的集合，而集合意味着多个，因此应当称他们为Customers表。除非你只有一个客户，但这种情况你根本用不着数据库。

根据笔者的非正式调查，有3/4的SQL Server开发人员支持使用单数命名。这些开发人员认为，客户表是客户的集合，而不是客户们的集合。一组行不应当也不会被成为rows set(行们的集合)，而会被称为row set(行集)。并且，通常在讨论时人们会使用单数名称来称呼表，说Customer表比说Customers表听起来更为清晰。

多对多关系中连接表的命名

大家知道，如果要实现两个实体间的多对多关系，需要三张表，其中一张是解析表。考虑下面这样一个多对多关系，这是经典的学生选课问题：一个学生可以选很多门课，一门课可以有很多学生。此时为了实现上面的关系，就需要一张解析表(这张表只存储学生ID和课程ID，而学生的信息和课程信息分别存在各自的表中)，这个表的起名，建议的写法是将两个表的表名合并(如果表名比较长可做简化)，此处如 StudentCourse。这个表中字段设为StudentId、CourseID(既是此表的复合主键，同时分别为连接Student表和Course表的外键，等下到主键和外键的命名处再说)，这样就实现了学生和课程之间的多对多关系，当然，这个关系还可以加点额外的东西，比如给StudentCourse表中加AccessLevel字段，值域D{只读,完全,禁止}，就可以实现访问级别。

主键的命名

按照SQL Server 的默认规范(使用企业管理器创建主键时默认产生的主键名)，主键的命名为 pk_TableName。主键是针对一个表的，而不是针对一个字段的，大家有时候在企业管理器中会见到一个表的两个字段前面都会有钥匙的图标(比如SQL Server 2000自带的NorthWind范例数据库的EmployeeTerritories表)，就会误以为主键是针对字段的，即是说一个表上有两个主键，其实错了，只有一个主键，但包含了两个字段，这就是常说的复合主键。为了有个更生动的认识，看下建立复合主键的SQL语句，以上面说到的多对多连接表StudentCourse为例：

Alter Table StudentCourse

Add Constraint pk_StudentCourse Primary key(StudentId, CourseId)

可见，对于主键pk_StudentCourse，包含了两个字段StudentId 和 CourseId

外键的命名

外键的命名为 fk_外键所在的表名_外键引用的表名。因为外键所在的表为从表，所以上式可以写为 fk_从表名_主表名

　　外键包含的字段的命名，外键包含的字段和外键是完全不同的概念。

　　考虑这样一个关系，表HotelInfo，字段HotelID,HotelName,FKCityID。表City,字段CityID,CityName。因为一个城市可能有好多家酒店，所以是一个一对多的关系，City是主表(1方)，HotelInfo是从表(多方)。在这个表中，FKCityID是做为外键使用，不少人建议外键的字段和引用的主表字段名称相同，但我发现这种情况在多对多关系的解析表中还清晰一些，在简单的一对多关系中还是给外键的字段加上FK前缀比较好，FK后面的为引用的主表的字段名。(附带着说一下：一般上习惯在创建表时只写主键约束，在表创建好之后再用Alter Table来创建外键关系，理由就不用解释了吧- -+)

　　在实现外键的时候我们可以这样写：

Alter Table HotelInfo

Add Constraint fk_HotelInfo_City Foreign Key (FKCityID) References City(CityID)

On Delete Cascade On update Cascade

很明显，fk_HotelInfo_City是外键的名字，FKCity是外键包含的字段的名字。

而对于多对多关系中解析表的外键包含的字段，由于本身也做复合主键,如果加上FK很容易让人迷惑，所以不再加FK前缀，我们可以这样写(再次回到学生选课的多对多例子中)：

建立解析表StudentCourse与Course表的外键关系：

Alter Table StudentCourse

Add Constraint fk_StudentCourse_Student Foreign Key (StudentId) References Student (StudentId) On Delete Cascade On update Cascade

建立解析表StudentCourse与PageGroup表的外键关系:

Alter Table StudentCourse

Add Constraint fk_StudentCourse_Course Foreign Key (CourseId) References Course(CourceId) On Delete Cascade On update Cascade

触发器的命名：

由三部分构成：

3           前缀(tr),描述了数据库对象的类型。

4           基本部分，描述触发器所加的表。

5           后缀(I、U、D)，显示了修改语句(Insert, Update及Delete)

存储过程的命名：

大家都知道，系统存储过程的前缀是 sp，这里我推荐大家使用 pr 作为自己定义的存储过程的命名。

同时，命名的规则是：采用自解释型的命名，比如：prGetItemById。

这里，有个有意思的地方值得深思。我们按上面规则命名存储过程的时候，可以用两种方式：

1、动词放前面，名词放后面。

2、名词放前面，动词放后面。

我个人推荐使用方式2，现在说说原因：

以NorthWind 为例，假如针对 Employees 表你有4个存储过程，分别命名为：prEmployeeInsert、prEmployeeUpdate、prEmployeeDelById、prEmployeeGetById

同时对于 ProdUCts 表你有类似的4个存储过程，分别命名为：prProductInsert、prProductUpdate、prProductDelById、prProductGetById

这时，你用企业管理器查看时，会发现存储过程像下面这样整整齐齐的排列：

prEmployeeDelById

prEmployeeGetById

prEmployeeInsert

prEmployeeUpdate

prProductDelById

prProductGetById

prProductInsert

prProductUpdate

很容易就会发现，当你的存储过程越多时，这种命名方法的优势就越明显。

　　我们能用到的暂时就是这些了，至于其他的命名，我觉得表1的规范是比较不错的，大家可以参考一下。

　　我发现公司用存储过程的地方不多，抱着学习的心态，我用存储过程把最复杂的酒店预定用存储过程改写了，我想其他人不管现在还是将来可能会有机会用到存储过程，所以这里把我在存储过程中使用的变量命名规范也贴出来吧。

表2.数据类型前缀