循序渐进讲解数据表的十二个设计原则

(1)不应针对整个系统进行数据库设计，而应根据系统架构中组件的划分，针对每个组件所处理的业务，进行组件单元的数据库设计；应尽可能减少对应于不同组件的数据库表之间的相关性。如果不同组件之间的表需要外键关联，尽量不要创建外键关联，只记录关联表的一个主键，这样可以保证组件对应的表的独立性，为重构系统或表结构提供可能。

(2)采用领域模型驱动和自顶向下的思想设计数据库。首先，分析系统业务，根据职责定义对象。对象要符合封装的特性，这样才能保证在一个对象中定义了与职责相关的数据项，并且这些数据项能够完整的描述职责，不会出现漏描述职责的情况。一个对象只有一个责任。如果一个对象负责两个或更多的责任，那么它应该被拆分。

(3)根据建立的领域模型映射数据库表。这时候就要参考数据库设计的第二范式:一个表中所有的非关键字属性都依赖于整个关键字。关键字可以是一个属性，也可以是多个属性的集合。不管是哪种方式，都要保证关键词能够得到保证。在确定关键词时，要保证关键词不会参与业务，不会出现更新异常。这时候解决的办法就是用一个自增的数值属性或者一个随机的字符串作为表的键。

(4)由于第一点中提到的领域模型驱动的方法是用来设计数据库表结构的，领域模型中的每个对象只有一个责任，所以对对象中的数据项不存在传递依赖。所以这种思想的数据库表结构设计从一开始就符合第三范式:一个表要符合第二范式，属性之间不存在传递依赖。

(5)同样，由于对象的单一责任和对象之间的关系反映了业务逻辑之间的关系，所以域模型中的对象分为主对象和从对象，从对象从1-N或N-N的角度进一步是主对象的业务逻辑，所以从对象和对象关系映射的表和表关联中不存在删除和插入异常。

(6)映射后得到的数据库表结构要按照第四范式进一步修改，保证没有多值依赖。这时候就要按照逆向工程的思路反馈到领域模型中去。如果表结构中存在多值依赖，则证明域模型中的对象至少有两个责任，应根据第一条修改设计。第四种范式:如果一个表满足BCNF，就不应该有多值依赖。

(7)经过分析，确认所有的表都满足二、三、四范式，表与表之间的关联尽量弱，以利于表字段和表结构的调整和重构。而且我认为数据库中的表是用来持久化一个对象实例在特定时间和特定条件下的状态的，它们只是一个存储介质。所以表与表之间没有很强的关联来表达业务(数据之间的一致性)。这个责任应该由系统的逻辑层来保证，这也保证了系统对不正确数据(脏数据)的兼容性。当然，从整个系统的角度来看，我们还是要尽一切努力保证系统不会产生脏数据。单从另一个角度来说，脏数据的产生在某种程度上是不可避免的，我们也要保证系统对这种情况的容错能力。这是一个折中的方案。

(8)所有表的主键和外键都要建立索引，组合属性的索引要有针对性(针对一些大数据和常用的检索方式)，提高检索效率。虽然建立索引会消耗一些系统资源，但是在比较搜索时搜索整个表的性能影响，尤其是表中数据量较大时，不加索引排序的性能影响时，还是值得提倡的。

(9)尽量少用存储过程。目前有很多技术可以替代存储过程的功能，比如“对象/关系映射”。把数据一致性的保证放在数据库里，对版本控制、开发部署、数据库迁移都会有很大的影响。但不可否认的是，存储过程在性能上是有优势的。因此，当系统中可用的硬件不会得到改进，并且性能是一个非常重要的质量属性时，可以在平衡考虑后选择存储过程。

(10)当处理表间关联约束的成本(往往是可用性的成本)超过了确保不会出现修改、删除或变更异常的成本，且数据冗余不是主要问题时，表的设计可能不符合四范式。四种范式保证了不会有例外，但也可能导致过于纯粹的设计，使得表格结构难以使用。所以设计的时候要综合判断。但是，它是一种确保首先满足四个范例，然后进行细化和修正的方法。

(11)设计的表要有良好的可用性，主要体现在查询时是否需要关联多个表和使用复杂的SQL技巧。

(12)设计的表格应尽可能减少数据冗余，以保证数据的准确性。有效控制冗余将有助于提高数据库的性能