SQL数据库对象命名详细文档.doc

SQL数据库对象命名详细文档 对于一个大项目来讲，数据库的设计命名规范是很重要的一个环节，好的表设计，让人看得很舒服，一看就明白是什么意思了，下面看到一篇很不错的数据库对象命名参考文档，所以整理分享给大家。 引言 编码规范是一个优秀程序员的必备素质，然而，有很多人非常注重程序中变量、方法、类的命名，却忽视了同样重要的数据库对象命名。这篇文章结合许多技术文章和资料，以及我自己的开发经验，对数据库对象的命名规则提出了一点建议，希望能为大家提供一些参考。 NOTE：虽然这篇文章名为“数据库对象命名参考”，实际上，在这篇文章中我不仅介绍了数据库命名的规则，连带讲述了在数据库设计与开发时所需要注意的几个问题。 基本命名规则 表1. 基本数据库对象命名 数据库对象 前缀 举例 表(Table)字段(Column)视图(View)存储过程(Stored procedure)触发器(Trigger)索引(Index)主键(Primary key)外键(Foreign key)Check约束(Check Constraint)Unique约束用户定义数据类型(User-defined data type)用户定义函数(User-defined function) 无无vprtrix_pk_fk_ck_uq_udtfn StudentTitlevActivityprDelOrdertrOrder_Dix_CustomerIDpk_Adminfk_Order_OrderTypeck_TableColumnuq_TableColumnudtPhonefnDueDate 关于命名的约定 变量(T-SQL编程中声明的变量)、过程(存储过程或触发器等)、实体(表、字段)应该根据他们所代表的实体意义和进程作用来命名： 表2.好的命名 和 不好的命名 范例 好的命名 不好的命名 @CurrentDate@ActivityCount@EquipmentTypeprCalculateTotalPrice @D@ActNum@ET@prRunCalc 还有一个常见的错误就是只使用面向计算机的术语，而不是面向公司业务的术语，比如ProcessRecord就是一个含糊不清的命名，应该使用一个进程业务描述来替换它，比如CompleteOrder. 如果完全根据上一条的要求，那么根据业务描述的过程名可能会变得很冗长，比如下面： prCountTotalAmountOfMonthlyPayments (计算每月付费的总金额) prGetParentOrganizationalUnitName (获取上级单位名称) 此时则应该考虑使用缩写： 如果可以在字典里找到一个词的缩写，就用这个做为缩写，比如：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无异于画蛇添足，个人认为直接用Guest做表名就可以了。 对于存储航班信息的表，