如果一个外人仔细地查看你的SQL Server数据设计时，你会感觉到窘迫吗？有没有可能在你的表中实现一个外键约束呢？你是否在字段中使用了正确的数据类型？你是否按规范定义的方式进行表/字段命名？或者数据库的体系结构是否让人很费解？数据库体系架构师Brian Walker根据他多年的SQL Server经验，提出了许多用于改进数据库设计和SQL Server性能的建议。

一些业务数据库的状况很糟糕。

我曾经在五个星期里检查过三个业务数据库，我至今仍然为我所发现的状况感到震惊。这些都是作为那些能够年产上百万美元公司的关键业务基础服务的SQL Server数据库。每天，上百个员工都依靠这些数据库来实现准确性、稳定性和性能。从我个人来说，我不再相信这些数据库能够存储我的iPod中的2，600首歌曲。

数据库支持它们各自的业务，但它们都受到性能问题的困扰。数据库中有许多问题，但这些业务仍然工作在这些服务器硬件和生产环境DBA的问题中。修复这些问题是非常困难的，因为已经有几个应用程序都有适应这些数据库设计缺点的代码。由于额外的开销和功能丢失，业务受到了影响。同时，数据库设计也使SQL Server变得脆弱。

过去的问题

那么，我所指的业务数据库到底哪些方面出了问题呢？答案是所有方面，而且非常严重。它们的规范化很差。有一些数据库表没有主键。表之间的许多关系都没有使用外键进行约束。索引的使用也很随意。重要的业务逻辑都堆积在触发器中。许多字段的数据类型是不恰当的。而对于一致性呢？可能参加“美国偶像”第一回合海选的竞争者的造型比这些数据库更有一致性的。

规范化的好处一般是很好理解的，所以我将不会花太多时间进行解释。可以这样说，这些数据库的表都还没有达到1NF的要求。表没有主键约束明显违反了1NF的规范。而且，有一些表还有包含多种定义值的字段。大多数表的大多数字段都是可为NULL的，这也违反了有争议性的1NF规范。我个人看来，我认为可为NULL的字段一定会给某些情况下的开发人员带来麻烦。

实现外键约束应该是第二特性，而保证数据统一的好处是很重要的原因。这些数据库的一些表包含很多很多的孤立行。这些数据库缺少合适的声明引用完整性（Declarative Referential Integrity，DRI)的结果会给COBOL程序员再来巨大的麻烦。其中一个数据库的几个表的状况更令人直冒冷汗的。下面是一个假定的类似的例子。

假定你有一个Book表，它有一个外键AuthorID字段。在大多数行中，AuthorID字段包含一个指向Author表的外键。在一些行中，AuthorID字段包含一个指向Editor表的外键。而在另一些行中，AuthorID字段包含指向Publisher表的外键。有另一个字段负责指出AuthorID字段包含的引用是哪一种类型的。因此，这是不可能实现一个外键约束的。我说得没错吧！

全面的和正确的DRI可以生成一些非常有用的SQL代码。举例来说，可以为所有的外键生成索引，这可以显著地提高JOIN子句调用的性能。生成索可以构成数据库开发的基础，从而我们不需要在性能调优时一个个地添加这些索引。另外一个例子，它还可以生成用于审计或日志目的的SQL Server触发器。通常，我认为触发器应该专门用于此类任务，而业务逻辑则由存储过程来完成。

在我所检查的数据库中有许多字段选用了不恰当的SQL Server数据类型。它们混淆使用了单字节（标准的）字符串和双字节（国际的）字符串。它们有许许多多固定长度的字符字段，如20，30，40和50。它们有许许多多字段使用了datetime数据类型，而其实smalldatetime数据类型应该更符合它们的要求。这些数据类型选择浪费了存储空间并且降低了读/写性能。

保持一致性

在这些数据库发现的技术问题让我很不安，而缺少足够的一致性让我更难受。不一致的最主要方面是命名规范。10个数据库开发人员就会有至少10个“最佳的”命名规范。当然，我也有我自己习惯的命名规范，但这里有一个忠告给那些还想创建一个规范的人。这就是：定义一个命名规范，然后再使用它。每一个地方，每时每刻都应该这样做。如果一个数据库中有许多的命名规范是非常糟糕的。

当你在定义一个命名规范时，你要确保考虑到了所有方面。要确定表名的单数或复数。要确定好缩写、大写、特殊字符和前/后缀的使用方法。要为所有对象定义一个命名规范。包括表、字段（主键、外键等）、存储过程、方法、视图、触发器、索引、主键约束、外键约束、检查约束和默认值。任何遗漏都可能造成混乱。

表结构的一致性和可推测性可以带来许多的好处。比如，对旧数据的存档和清理会受到表结构的很大影响。这可能是你处理关系数据库时可能遇到的最复杂的事了。正确的做法是先选择一个父记录行（或一组父记录行），然后在派生表中复制/删除它和每一个相关的记录行。如果所有的表都有一致的结构，你就可以通过简单地调用存储过程来实现存档和清理。

我检查的这些数据库同时使用了几个不同的表结构。主键字段是不可推测的。外键字段也是不可以推测。审计字段也一样不可以推测。同时IDENTITY属性的使用也是不可推测的。因此，进行存档和清理需要为每一个表仔细编写特定的SQL代码来实现，这给维护带来巨大的工作量。在我个人看来，我认为表结构的不一致可能是许多业务数据库的最严重的设计缺点。

请阅读第二部分《SQL Server数据库设计灾难：它是如何开始的》，Walker会为你解释业务数据库糟糕的现状是怎么样的，以及你应该如何避免这些麻烦。

Brian Walker是一位独立的系统架构师、应用开发人员、数据库开发人员、数据库管理员和数据库顾问。他有30年的IT经验，最近几年他主要关注于SQL Server数据库架构。Walker与Wingenious公司联系紧密，这是一个使用Microsoft 技术的Web应用开发公司。