众所周知，数据库设计的好坏直接关系到数据库运行的效率。根据笔者的经验，对于提升数据库性能来说，合理的数据库设计，比升级服务器的硬件配置，还要来的有效。但是，笔者无论是在跟同事合作，又或者是在论坛上跟相关同行交流的时候，总是会发现有些人有一些不好的数据库设计习惯，影响了数据库的性能，增加了数据库管理员的工作量。

　　笔者认为，为了提升数据库的性能，在Oracle数据库设计的时候，要做到五戒。

　　一戒：在小型表上不要建立索引。

　　毋庸置疑，索引可以提高数据库查询的效率。但是，俗话说，过之则不及。索引也必须用在合时的地方。如果索引设置不当，不但不会提升数据库的性能，反而会起到相反的作用。如在小型数据库上设置索引，而且这些表用户更改的比较频繁。如员工基本信息表，就是简单的不超过十个字段。这个表用户需要经常的进行插入与删除操作。当进行这些变更作业的时候，需要对索引进行维护。而这个维护的工作量可能比扫描表空间消耗更多的存储空间。从而不但起步到改善数据库性能的作用，反而是在拖后腿。

　　所以，在数据库设计的时候，要做到的第一个戒条就是，不要再用户经常更改的小型表上建立索引。否则的话，是得不偿失的。

　　二戒：不要用用户的键。

　　如我们在设计一个ERP系统数据库的时候，有一张销售订单表。在这张表中，有一个销售订单号。那么我们能否利用这个单号作为关联其他表的外键呢?如在销售出货单上，需要关联到销售订单。这个时候，我们能否把销售订单单号作为跟出货单关联的关键字呢?

　　答案是可以的，但是不是最优选择。我们可以看一下ERP的后台数据库。在销售订单表上，除了销售订单号这个唯一表示销售订单纪录的字段外，还有一个字段就是销售订单ID。在前台的出货单界面上虽然显示的是销售订单号码，但是，在后台却存储着的是销售订单ID。也就是说，数据库不是以用户的键作为主键，而是采用了数据库自动维护的单据ID这个字段。

　　为什么要这么设计呢?这就是笔者今天要谈的第二个戒条，不要用用户的键。通常情况下，不要选择用户可编辑的字段作为外键或者主键。因为这会增加我们额外的工作量。

　　如果我们把销售订单号作为外键的话，则在创建销售订单纪录后还要对用户编辑字段的行为施加限制，如判断是否违反外键的强制性规则等等。有些系统把销售订单号设置为外键的话，则往往是把这个字段设置为系统自动编号，并且用户不可更改。可是，在实际工作中，企业员工往往需要编辑这个字段。员工需要编辑这些不可编辑的字段时系统缺乏灵活性的缺陷就体现出来了。而且，当用户输入完数据保存的时候再提示纪录不符合要求，则也不是很人性化的设计。

　　另外，我们还必须为此设计一些检测和纠正键冲突的方法。如考虑这个外键的直是否在其他数据表中存在等等。虽然这通常只需要我们花点时间就可以搞定。但是从数据库性能上来说，这个代价就比较大了。再则，如此的话，就不能够很好的把系统的基本数据跟企业员工的数据实现很好的隔离。

　　所以，笔者认为，不要用用户的键来作为我们数据库设计的主键或则外键。或者说，数据库设计时用到的键要让数据库系统进行自动维护，用户不得更改这个维护规则。

　　三戒：不要用商务规则来实现数据的完整性。

　　数据的完整性有好几种实现方法。如可以通过数据库约束实现数据完整性;也可以通过前台系统的商务规则来实现数据的完整性。不过，笔者这里要建议的是，在一些大型的数据库中，不要试图通过商务规则来实现数据的完整性，而尽可能的通过数据库的约束来实现。因为若通过商务规则来实现完整性，往往会出现一些莫名其妙的错误。

　　如笔者就遇到过这一个案例。在数据库设计的时候，把某个字符型字段长度限制为最长50位。而在前台应用程序中，却限制了60位。在员工数据数据的时候，在前台应用程序中，可以输入55个字符。但是，下次用户查询的时候，却发现后面几个字符没有了，只剩下前面那些内容。这主要是因为在数据保存的时候，超过了数据库的最长位数限制。数据库就会自动把后面几个字符去掉然后保存。如此，用户在前台输入数据的时候，以为可以保存。但是，实际上数据库中存储的数据是不全的。

　　所以，笔者的第三个戒条就是，不要利用商务规则在前台实现数据的完整性。只要有可能，就要尽量在数据库系统层面实现数据的完整性。在数据库层面实现数据完整性的同时，需要注意用户的友好性。

　　一是要把违反约束信息尽可能详细的回馈给用户。如销售订单号，在数据库系统中设置了唯一性约束。则当用户在建立销售订单的时候，销售订单号重复时，就需要把这个约束的详细信息反馈给前台用户。若只显示不能够保存这个错误信息往往是不够的。这会让用户摸不着头脑。