数据库对象命名
基本命名规则
| 数据库对象 |
前缀 |
举例 |
| 表(Table) | 无 | Student |
| 字段(Column) | 无 | Title |
| 视图(View) | v | vActivity |
| 存储过程(Stored procedure) | pr | prDelOrder |
| 触发器(Trigger) | tr | trOrder_D |
| 索引(Index) | ix_ | ix_CustomerID |
| 主键(Primary key) | pk_ | pk_Admin |
| 外键(Foreign key) | fk_ | fk_Order_OrderType |
| Check约束(Check Constraint) | ck | ck_TableColumnName |
| Unique约束 | uq_ | uq_TableColumnName |
| 用户定义数据类型(User-defined data type) | udt | udtPhone |
| 用户定义函数(User-defined function) | fn | fnDueDate |
关于命名的约定
变量(T-SQL编程中声明的变量)、过程(存储过程或触发器等)、实体(表、字段)应该根据他们所代表的实体意义和进程作用来命名：
| 好的命名 | 不好的命名 |
| @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？
我主张起单数表名，下面是来自《SQL Server 2000 宝典》的一段引用：
主张用复数表名的阵营认为：表是由一组记录构成的，所以应当使用复数名词来命名它。他们经常使用的理由是：客户表是客户们的集合，而集合意味着多个，因此应当称他们为Customers表。除非你只有一个客户，但这种情况你根本用不着数据库（很搞的一句话）。
据非正式调查，有3/4的SQL Server开发人员支持使用单数命名。这些开发人员认为，客户表是客户的集合，而不是客户们的集合。一组行不应当也不会被成为rows set(行们的集合)，而会被称为row set(行集)。并且，通常在讨论时人们会使用单数名称来称呼表，说Customer表比说Customers表听起来更为清晰。
避免无谓的表格后缀
这两点我想大家都知道：1、表是用来存储数据信息的。2、表是行的集合。
那么如果表名已经能够很好地说明其包含的数据信息，就不需要再添加体现上面两点的后缀了。
实际工作中，我看到有的同事对表这样命名：GuestInfo，用于存储客户信息。这个命名与上面所说的第1点重复，谁都知道表本来就是存储信息(information)的，再加个Info无异于画蛇添足，个人认为直接用Guest做表名就可以了。
对于存储航班信息的表，他又命名为FlightList。这个命名又与之前说的第2点相重复，表是行的集合，那么自然是列表(List)，加上List后缀显得很多余，命名为 Flight 不是很好么？可见，他自己都没有订立一个明确的命名规则，不然这两个表一定是要么命名为：GuestList、FlightList 要么命名为 GuestInfo、FlightInfo，而不会是两者的混合。
多对多关系中连接表的命名
大家知道，如果要实现两个实体间的多对多关系，需要三张表，其中一张是解析表。考虑下面这样一个多对多关系，这是一个经典的学生选课问题：一个学生可以选很多门课，一门课可以有很多学生。此时为了实现上面的关系，就需要一张解析表(这张表只存储学生ID和课程ID，而学生的信息和课程信息分别存在各自的表中)，这个表的起名，建议的写法是将两个表的表名合并(如果表名比较长可做简化)，此处如 StudentCourse。这个表中字段分别命名为StudentID、CourseID(既是此表的复合主键，同时分别为连接Student表和Course表的外键，等下到主键和外键的命名处再说)，这样就实现了学生和课程之间的多对多关系，当然，这个关系还可以加点额外的东西，比如给StudentCourse表中加AccessLevel字段，值域D{只读,完全,禁止}，就可以实现访问级别。
约定俗成的字段名前/后缀
数据库开发的时间久了，慢慢就会摸索出一个规律来：就是很多的字段都有些共同的特性。比如说，有的字段是代表时间的(例如发帖时间，评论时间)，有的是代表数量的(例如浏览数，评论数)，有的是代表真假类型的(例如是否将博客随笔显示在首页)。对于这种同一类型的字段，应该使用统一的 前缀 或者 后缀去标识它。
我们来举几个例子看得更明白一点。
以大家都熟悉的论坛来说，需要记录会员最后一次登录的时间，这时候一般人都会把这个字段命名为LoginTime 或者 LoginDate。这时候，已经产生了一个歧义：对于另一名开发者来说，如果仅看表的字段名称，不去看表的内容，很容易将LoginTime理解成登录的次数，因为，Time还有一个很常用的意思，就是次数。
为了避免这种情况发生，应该明确的规定：所有表示时间的字段，统一以 Date 来作为结尾。
我们经常需要统计发帖数、回帖数信息，这时候，开发人员通常会这样去命名字段：PostAmount、PostTime、PostCount，同样，由于Time的歧义，我们首先排除掉不使用PostTime作为字段名。接下来，Amount 和 Count 都可以表示计数的意思，用哪个合适呢？这里，我推荐使用Count。为什么呢？如果你做过Asp开发，相信一定知道 RecordCount 这个属性，命名的时候有一个原则：就是使用约定俗成的名称，而不要去自创名称。既然微软都用Count后缀来表示数目，我们为什么不呢？
于是，所有表示数目的字段，都应该以Count作为结尾。将这一概念做以推广，很容易得出，浏览次数为 ViewCount，登录次数为LoginCount 等等。
再举一个例子，我们很少在数据库里直接保存图片等二进制数据，通常是仅保存图片的URL路径；在文章管理系统中，如果是转载文章，也会用到记录文章出处的字段。个人建议所有代表链接的字段，均为Url结尾。于是，图片路径的字段命名为 ImageUrl，文章出处字段的命名为SourceUrl。
最后一个例子，我们经常需要用到布尔值，比方说，这篇随笔要不要显示到首页，这篇随笔是不是保存到草稿箱等等。同样，按照微软的建议，布尔类型的值均以 Is、Has 或者 Can开头。