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

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

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

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

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

二是在必要的时候，可以利用触发器来实现数据的完整性。虽然在功能设计上，我们不建议在Oracle数据库中采用触发器来实现。如要把某个小写金额转换为大小金额。我们是建议通过前台应用程序实现。因为应用程序的执行效率要比数据库的触发器高。但是，在数据库数据完整性上，在必要的时候，若靠数据库约束无法实现完整性，我们仍然建议采用触发器，而不是前台应用程序来实现。在任何情况下，不要依赖于应用程序来实现数据完整性。否则的话，很难保证数据库约束与商务层约束的一致性。

四戒：在可能的情况下，不要让前台应用程序直接访问数据表。

其实，在数据库基础表与前台应用程序之间，还有一个很好的“中间人”，那就是视图。试图是数据库基础表的一个抽象。他除了可以保障数据的质量外，还可以有效的访问前台应用程序对于数据的非法访问。所以，一些安全性级别比较高的数据库系统，在数据库设计的时候，往往会在数据库和前台应用程序代码之间提供“视图”这个中间人，让其作为基础表的“新闻发言人”。如此，前台应用程序在没有必要的情况下，可以不直接访问数据表，而是通过视图来对表实现间接的访问。

如在进行数据导入程序设计的时候，通过视图来实现则是一个很理想的方法。如用户现在要导入产品信息，包括产品基本信息、供应商信息、价格信息等等。这些信息在数据库中往往包含在三种表中，分别为产品基本信息表、供应商信息表、产品价格信息表。若前台应用程序直接访问基础表的话，就需要分别访问这三张基础表。这不但效率比较低，而且也不容易实现数据的完整性。此时，我们就可以利用视图，把一些必须要填入的字段组合在一张可更新视图中。如此，前台应用程序只需要访问一个数据库对象即可。

再者，在数据库报表设计上，更是要通过视图来实现。而不要通过传递一段SQL代码来查询基础表。这对于数据的安全性会带来比较大的威胁。

所以，第四个戒条就是，在可能的情况下，不要让前台应用程序直接访问数据表。

五戒：不要一直让用户输入数据。

有些字段其实不一定要让用户输入，只需要用户选择即可。如在人事管理系统中，企业员工所属的民族、职位、省份等等就没有必要让用户手工输入。而可以通过列表的形式让员工来进行选择。这种手段，是提高数据完整性的最佳方式之一。若能够给用户提供一个详细的列表供其选择，这样将减少键入代码的错误，同时提高数据库的一致性;也可以提高用户界面的友好性。

所以，在数据库设计的时候，尽量使用列表字段来供用户选择。若连省份等等字段都要用户手工输入的话，则我们在数据库完整性所花费的时间，就要很多。如在数据保存的时候，都要去判断用户输入的数据是否合乎完整性的规则。这显然工作量要比设计一个列表字段多得多。

故数据库设计的第五个戒条就是不要老是让用户手工输入数据。提供列表让用户进行选择，用户不仅可以提高效率，我们也可以省事，同时，也能够保障数据的准确率。