数据库对象命名参考.doc

数据库对象命名参考
本文是一个参考,不是一个规范,更不是一个标准。它仅代表了我个人的观点和建议,并只考虑了通常条件下的规则,你可以根据实际情况随意修改它。
引言
编码规范是一个优秀程序员的必备素质,然而,有很多人非常注重程序中变量、方法、类的命名,却忽视了同样重要的数据库对象命名。这篇文章结合许多技术文章和资料,以及我自己的开发经验,对数据库对象的命名规则提出了一点建议,希望能为大家提供一些参考。
NOTE:虽然这篇文章名为“数据库对象命名参考”,实际上,在这篇文章中我不仅介绍了数据库命名的规则,连带讲述了在数据库设计与开发时所需要注意的几个问题。
基本命名规则
表1. 基本数据库对象命名
数据库对象
前缀
举例
表(Table)
字段(Column)
视图(View)
存储过程(Stored procedure)
触发器(Trigger)
索引(Index)
主键(Primary key)
外键(Foreign key)
Check约束(Check Constraint)
Unique约束
用户定义数据类型(User-defined data type)
用户定义函数(User-defined function)
无
无
v
pr
tr
ix_
pk_
fk_
ck_
uq_
udt
fn
Student
Title
vActivity
prDelOrder
trOrder_D
ix_CustomerID
pk_Admin
fk_Order_OrderType
ck_TableColumn
uq_TableColumn
udtPhone
fnDueDate
关于命名的约定
变量(T-SQL编程中声明的变量)、过程(存储过程或触发器等)、实体(表、字段)应该根据他们所代表的实体意义和进程作用来命名:

好的命名
不好的命名
***@CurrentDate
***@ActivityCount
***@EquipmentType
prCalculateTotalPrice
***@D
***@ActNum
***@ET
***@prRunCalc
还有一个常见的错误就是只使用面向计算机的术语,而不是面向公司业务的术语,比如ProcessRecord就是一个含糊不清的命名,应该使用一个进程业务描述来替换它,pleteOrder.
如果完全根据上一条的要求,那么根据业务描述的过程名可能会变得很冗长,比如下面:
prCountTotalAmountOfMonthlyPayments (计算每月付费的总金额)
anizationalUnitName (获取上级单位名称)
此时则应该考虑使用缩写:
如果可以在字典里找到一个词的缩写,就用这个做为缩写,比如:Mon(Monday)、Dec(December)
可以删除单词元音(词首字母除外)和每个单词的重复字母来缩写一个单词。比如:Current = Crnt、Address = Adr、Error = Err、Average = Avg
不要使用有歧异的缩写(一般是语音上的歧义)。比如b4(before)、xqt(execute),4tran(Fortran)
表格、字段的命名:
单数表名、字段名还是复数表名、字段名?
可能大家很少会考虑到给表名起单数还是复数,比如,对存储客人信息的表,我们应该起Customer,还是Customers?我主张起单数表名,下面是来自《SQL Server 2000 宝典》的一段引用:
主张用复数表名的阵营认为:表是由一组记录构成的,所以应当使用复数名词来命名它。他们经常使用的理由是:客户表是客户们的集合,而集合意味着多个,因此应当称他们为Customers表。除非你只有一个客户,但这种情况你根本用不着数据库。
根据笔者的非正式调查,有3/4的SQL Server开发人员支持使用单数命名。这些开发人员认为,客户表是客户的集合,而不是客户们的集合。一组行不应当也不会被成为rows set(行们的集合),而会被称为row set(行集)。并且,通常在讨论时人们会使用单数名称来称呼表,说Customer表比说Customers表听起来更为清晰。
避免无谓的表格后缀
这两点我想大家都知道:1、表是用来存储数据信息的。2、表是行的集合。那么如果表名已经能够很好地说明其包含的数据信息,就不需要再添加体现上面两点的后缀了。
实际工作中,我看到有的同事对表这样命名:GuestInfo,用于存储客户信息。这个命名与上面所说的第1点重复,谁都知道表本来就是存储信息(information)的,再加个Info无异于画蛇添足,个人认为直接用Gu