一些本来很简单的事物却被人为地变得极度复杂、令人迷惑，这似乎是一个普遍的现象。在创建数据库时，对象应按照某种合理的命名规范来命名。命名规范没有业内通用的标准，人们对于什么是合理的命名规范意见不一。大多数人认为这是简单的常识，于是他们不在此花太多精力。但问题是，没有通用的命名规范，每个人都认为自己的命名规范是合理的。
如果有一个简单的标准，就会十分方便。尽管对象命名并不复杂，但它是有艺术性的，有许多方面需要考虑：比如，最好使用能完整描述每个对象的用途的名字。另外，名字应简短、简洁，这样用户就不必花很多精力打字了。两者有时候是相互矛盾的。
一般规则是，在SQL Server中创建对象时，如果查询编辑器把名字的颜色从黑色变成其他颜色，就应避免使用该名字。但Microsoft中的系统对象和AdventureWorks2008数据库中的示例对象名常常违反这个规则。还要注意，查询编辑器会改变已配置的所有单词的颜色，以便于识别。这些单词包括SQL保留字、函数和系统对象、ODBC保留字和将来的保留字。因此，并不是所有改变颜色的单词都是保留字。例如，在打开的查询窗口中输入Description，该单词就会变成蓝色，不经任何特殊处理就可以被使用，但Management Studio会把它识别为一个潜在的保留字。
一些旧的数据库产品不支持混合大小写的名字或者包含空格的名字。因此，虽然混合大小写的名字不容易产生视觉疲劳。许多数据库管理员仍旧使用全小写的名字，名字中的词用下划线隔开。
流行的东西总是来去匆匆。当Windows 95推出时，Microsoft推广使用长文件名，同时开发的Microsoft Access也推广使用长数据库对象名。从某个方面来说，使用友好的、类似于句子的描述性名字是符合情理的。实际上，SQL Server能够处理带空格的名字，但是解决方案中的其他组件可能会有问题。值在应用程序的不同级别上处理过程是：首先从用户界面的控件传递到程序代码的变量中，然后传递到方法的参数或者类的属性中，最终，这些值作为参数传递到存储过程中，作为字段名传送到SQL语句中。其要点是，如果这些项有相同或相似的名字，每个参与者操作起来会更容易一些。
在数据库使用带空格的字段名，在其他地方使用不带空格的相似名字不会有什么坏处。但数据库专家普遍认为，对象名中不应该有空格，坦率地说，这更多的是观念问题，而不是技术可行性问题。但编写代码时使用内嵌空格的引用对象，容易引发错误和应用程序异常。如果应用程序开发人员需要创建程序来访问数据库，最好避免使用内嵌空格的对象名。
我做过很多由单人完成的解决方案开发工作，既要创建数据库，又要写软件组件，设计开发用户界面，还要编写所有的程序代码，并把这些组件关联到一起。即使在这些应用程序中，如果相关的对象名不相同，仍旧容易迷失方向，因此这些对象名在整个解决方案中最好是一致的。我也曾经参与了一些大型的复杂项目，在这些项目中，数据库是很久以前由其他人设计的。如果从一开始名字就不清晰、不简练，就会出现两难的局面：是在程序代码中把名字起得容易理解一些(它们与表和字段名不匹配是可以接受的)，还是在整个解决方案中使用与数据库相同、但容易混淆的名字呢？
数据库设计人员在建模与创建表格时，常常会使用自己的命名习惯为表与字段命名。这个人去做其他工作后，另一个数据库专家加入进来，添加了一些存储过程。他可能不同意原来的设计人员所用的名字，于是他给存储过程和输入参数命名的规范不同于表中的字段。这时又来了一位顾问开发软件组件，他给对应于字段和参数的相关类属性使用缩写名。后来，一位初级软件开发人员利用这些数据创建了一个用户应用程序，他参加了一个培训班，或者读了一本关于正确命名对象的书，决定使用自己的命名规范来解决问题，而不管已存在的名字。巧合的是，我今天刚修改了一些报表查询，设计了这些报表所使用的表。在测试时，发现性能不理想，于是决定建立另一个带有预聚合数据的表。另一个数据库设计人员帮忙为一些列命名，但命名方法和我不一样。比如，我把一个列命名为FiscalMonthYear Number，而他命名为FiscalMonthNumber。虽然这件事的影响不是很大，但是我却不得不修改所有报表中的查询。
这个常见的问题没有简单的解决方法。理想情况是，数据库的设计者应认真考虑名字的影响，并全面地解释它们。这就为后来者设立了标准--所有的名字都应保持一致。我通常使用大小写混合的名字，将每个词的首字母大写，然后把它们连接起来。在编程中，这通常称为Pascal Case，这是以Pascal编程语言的名字命名的。表4-1展示了一些常见的命名标准以及它们的历史和优缺点。
表 4-1
|
命 名 标 准 |
例 子 |
描 述 |
|
Pascal Case |
CustomerFirstName |
所有单词的首字母都是大写， 直接连接在一起，不用使用分隔符 |
|
Camel Case |
customerFirstName |
除了第一个单词的首字母大写外， 其余字符都是小写。这个标准 通常用于XML元素名，在数据库 对象命名中不常见 |
|
Hungarian |
VcCustomerFirstNamemstr |
对象带有代表数据类型与/或范围的 前缀。这个标准更常用于程序代码， 而不是数据库对象的命名。真正的 匈牙利表示法非常复杂、冗长 |
|
Lower-case, delimited |
customer_first_name |
来自于不支持混合大小写的老数据库 产品。由于向后兼容性与传统习惯的 原因，目前仍在被广泛使用 |
|
Long Names |
Customer First Name |
在Microsoft的产品中推广，如Access。 具有易读的优点，但是通常不用于严 肃的软件解决方案。可能存在与相关 的程序代码不兼容的情况 |