数据库对象的命名探讨(网上搜集)
关于命名的约定：变量(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？我主张起单数表名，下面是来自《SQL Server 2000》一段引用：
主张用复数表名的阵营认为：表是由一组记录构成的，所以应当使用复数名词来命名它。他们经常使用的理由是：客户表是客户们的集合，而集合意味着多个，因此应当称他们为Customers表。除非你只有一个客户，但这种情况你根本用不着数据库。
根据笔者的非正式调查，有3/4的SQL Server开发人员支持使用单数命名。这些开发人员认为，客户表是客户的集合，而不是客户们的集合。一组行不应当也不会被成为rows set(行们的集合)，而会被称为row set(行集)。并且，通常在讨论时人们会使用单数名称来称呼表，说Customer表比说Customers表听起来更为清晰。
多对多关系中连接表的命名
大家知道，如果要实现两个实体间的多对多关系，需要三张表，其中一张是解析表。考虑下面这样一个多对多关系，这是经典的学生选课问题：一个学生可以选很多门课，一门课可以有很多学生。此时为了实现上面的关系，就需要一张解析表(这张表只存储学生ID和课程ID，而学生的信息和课程信息分别存在各自的表中)，这个表的起名，建议的写法是将两个表的表名合并(如果表名比较长可做简化)，此处如 StudentCourse。这个表中字段设为StudentId、CourseID(既是此表的复合主键，同时分别为连接Student表和Course表的外键，等下到主键和外键的命名处再说)，这样就实现了学生和课程之间的多对多关系，当然，这个关系还可以加点额外的东西，比如给StudentCourse表中加AccessLevel字段，值域D{只读,完全,禁止}，就可以实现访问级别。
字段命名时需注意的一个问题
我发现有很多人喜欢给字段加上表名作为它的前缀，举个例子，如果有个表叫User，那么他就会将这个表中的字段命名为：UserId、UserPassword、UserName、UserPhone 等等，其实是没有必要的，因为你已经确切的知道了这个表存储的是User的信息，那么其中的字段必然是针对于User的。而且，在Join连接操作中，你的SQL代码看上去也会更加的精简一些，诸如 [User].UserName = Aritcle.ArticleAuthor 这样的代码完全可以实现为 [User].Name = Article.Author。
但是，这里还存在一个特例，就是表的主键，有的人直接用ID做表的主键，而我倾向于用“表名+ID”的方式，比如 ArticleId 、UserId 等。
主键的命名
按照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
触发器的命名：
由三部分构成：
前缀(tr),描述了数据库对象的类型。
基本部分，描述触发器所加的表。
后缀(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
很容易就会发现，当你的存储过程越多时，这种命名方法的优势就越明显。
