数据库的设计 命名原则.docVIP

数据库设计 命名原则 本文是一个参考，不是一个规范，更不是一个标准。它仅代表了我个人的观点和建议，并只考虑了通常条件下的规则，你可以根据实际情况随意修改它。 引言 编码规范是一个优秀程序员的必备素质，然而，有很多人非常注重程序中变量、方法、类的命名，却忽视了同样重要的数据库对象命名。这篇文章结合许多技术文章和资料，以及我自己的开发经验，对数据库对象的命名规则提出了一点建议，希望能为大家提供一些参考。 NOTE:虽然这篇文章名为数据库对象命名参考，实际上，在这篇文章中我不仅介绍了数据库命名的规则，连带讲述了在数据库设计与开发时所需要注意的几个问题。 基本命名规则 表1.基本数据库对象命名数据库对象前缀举例 表(Table)无Student 字段(Column)无Title 视图(View)vvActivity 存储过程(Storedprocedure)prprDelOrder 触发器(Trigger)tdtrOrder_D 索引(Index)ix_x_CustomerID 主键(Primarykey)pk_pk_Admin 外键(Foreignkey)fk_fk_Order_OrderTypeCheck约束(CheckConstraint)ck_ck_TableColumnUnique约束uq_uq_TableColumn 用户定义数据类型(User-defineddatatype)udtudtPhone 用户定义函数(User-definedfunction)fnfnDueDate 关于命名的约定 变量(T-SQL编程中声明的变量)、过程(存储过程或触发器等)、实体(表、字段)应该根据他们所代表的实体意义和进程作用来命名: 表2.好的命名和不好的命名范例好的命名不好的命名 @CurrentDate@D @ActivityCount@ActNum @EquipmentType@ET @prCalculateTotalPrice@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?我主张起单数表名，下面是来自《SQLServer2000宝典》的一段引用: 主张用复数表名的阵营认为:表是由一组记录构成的，所以应当使用复数名词来命名它。他们经常使用的理由是:客户表是客户们的集合，而集合意味着多个，因此应当称他们为Customers表。除非你只有一个客户，但这种情况你根本用不着数据库。 根据笔者的非正式调查，有3/4的SQLServer开发人员支持使用单数命名。这些开发人员认为，客户表是客户的集合，而不是客户们的集合。一组行不应当也不会被成为rowsset(行们的集合)，而会被称为rowset(行集)。并且，通常在讨论时人们会使用单数名称来称呼表，说Customer表比说Customers表听起来更为清晰。 避免无谓的表格后缀 这两点我想大家都知道:1、表是用来存储数据信息的。2、表是行的集合。那么如果表名已经能够很好地说明其包含的数据信息，就不需要再添加体现上面两点的后缀了。 实际工作中，我看到有的同事对表这样命名:GuestInfo，用于存储客户信息。这个命名与上面所说的第1点重复，谁都知道表本来就是存储信息(information)的，再加个Info无异于画蛇添足，个人认为直接用Guest做表名就可以了。 对于存储航班信息的表，他又命名为FlightList。这个命名又与之前说的第2点相重复，表是行的集合，那么自然是列表(List)，加上List后缀显得很多余，命名为Flight不是很好么?可见，他给自己都没有订