数据库开发历史上一直使用一个有点神秘的系统命名数据库表和字段。最初的数据库管理系统（DBMS ） ，这些命名方案的限制的结果已成为惯例和传统。然而，随着数据库应用程序变得越来越复杂，更多的表和更大的开发团队，并为开发人员来来去去，它变得更加重要，实现数据库对象一个强大的，有纪律的命名方案。一个良好定义的命名方案，当你采用对象关系映射（ORM ）技术或自动代码生成变得更加重要。
命名表
在大多数数据库中，有三种类型的表：
1、数据表（Data Tables ） - 当然，在一个数据库中所有表包含数据，但我使用这个词来指代实际存储，而我们被刺激生成数据库，开始与数据，如客户，订单或产品的表。例如，一个客户表包含与如姓名，地址和电话领域的有关客户的信息。客户是一个数据表 - 不像其他这些表类型。
2、链接表（Link Tables）- 链接表做的无非就是连接两个不同的数据表的两个关键领域，形成许多一对多的关系。例如，你可以有一个供应商表和产品表之间的许多一对多的关系，因为每个供应商可以支持多个产品，每个产品可以通过多个供应商进行销售。这将需要一个第三表向卖方链接到的产品。
3、选择表（Picklist Tables ） - 这是常见的有内含的选择在数据表中的字段列表的表。例如，你可能在你的供应商表中的状态字段。值对供应商的地位可以从另一个表中选择。我指的是这些类型的表作为“选择”表，因为它们允许用户从列表中选择。
在我的命名方案，我想每个前缀的表名与三个前缀之一，以指示表的类型。我用下面的前缀：
数据表 - 我用的前缀TBL 。所以，记住我的规则大小写混合的，没有下划线，你可以有以下数据表：
tblCustomer
tblOrder
tblOrderEntry
tblVendor
tblProduct
链接表 - 我用的是前缀的链接。因此，与产品供应商联系起来，你将有一个表linkVendorProduct 。
选择表 - 我用的前缀pltbl 。因此，对于供应商的地位，你将有一个名为pltblVendorStatus表。如果你也有对客户状态的表，你可以有pltblCustomerStatus。
优点：
我发现这个表命名系统具有几个优点。
1、显然，这是很容易从表名告诉是包含什么样的数据表。
2、我所见过的（如Microsoft Access或SQL Server ），每个数据库的应用程序，按字母顺序列出你的表。使用这个前缀方案会使你的表是由类型时，按字母顺序显示分组。
3、如果你开发任何种类的自动代码生成工具，很容易通过编程从什么样的数据表中包含的表名来确定。您只需检查前缀。
单数/复数名
请注意，在上面我的数据表，所有的表名是单数，即tblCustomer而不是tblCustomers 。无论您喜欢单数或复数名称，你应该总是使用一个或另一个一致。我更喜欢单数，因为它似乎更清洁的给我。
其他表类型如：
记录表（log tables）
错误表（error tables）
系统表（system tables）
每个这些可以有他们自己的前缀。
基本命名规则
表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编程中声明的变量)、过程(存储过程或触发器等)、实体(表、字段)应该根据他们所代表的实体意义和进程作用来命名：
表2.好的命名 和 不好的命名 范例
| 好的命名 |
不好的命名 |
@CurrentDate
@ActivityCount
@EquipmentType
prCalculateTotalPrice |
@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
避免无谓的表格后缀
这两点我想大家都知道：1、表是用来存储数据信息的。2、表是行的集合。那么如果表名已经能够很好地说明其包含的数据信息，就不需要再添加体现上面两点的后缀了。
实际工作中，我看到有的同事对表这样命名：GuestInfo，用于存储客户信息。这个命名与上面所说的第1点重复，谁都知道表本来就是存储信息(information)的，再加个Info无异于画蛇添足，个人认为直接用Guest做表名就可以了。
对于存储航班信息的表，他又命名为FlightList。这个命名又与之前说的第2点相重复，表是行的集合，那么自然是列表(List)，加上List后缀显得很多余，命名为 Flight 不是很好么？可见，他给自己都没有订立一个明确的命名规则，不然这两个表一定是要么命名为：GuestList、FlightList 要么命名为 GuestInfo、FlightInfo，而不会是两者的混合。
多对多关系中连接表的命名
大家知道，如果要实现两个实体间的多对多关系，需要三张表，其中一张是解析表。考虑下面这样一个多对多关系，这是一个经典的学生选课问题：一个学生可以选很多门课，一门课可以有很多学生。此时为了实现上面的关系，就需要一张解析表(这张表只存储学生ID和课程ID，而学生的信息和课程信息分别存在各自的表中)，这个表的起名，建议的写法是将两个表的表名合并(如果表名比较长可做简化)，此处如 StudentCourse。这个表中字段分别命名为StudentId、CourseID(既是此表的复合主键，同时分别为连接Student表和Course表的外键，等下到主键和外键的命名处再说)，这样就实