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

数据表的设计原则:

1)不应针对全部系统进行数据库设计，而应当根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，假如不同组件间的表需要外键关联也尽量不要创立外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构供给可能性。

(2)采用范畴模型驱动的方法和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封装的特征，确保与职责相干的数据项被定义在一个对象之内，这些数据项能够完整描写该职责，不会呈现职责描写缺失。并且一个对象有且只有一项职责，假如一个对象要负责两个或两个以上的职责，应进行分拆。

(3)根据建立的范畴模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非要害字属性都依附于全部要害字。要害字可以是一个属性，也可以是多个属性的聚集，不论那种方法，都应确保要害字能够保证唯一性。在断定要害字时，应保证要害字不会参与业务且不会呈现更新异常，这时，最优解决计划为采用一个自增数值型属性或一个随机字符串作为表的要害字。

(4)由于第一点所述的范畴模型驱动的方法设计数据库表结构，范畴模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依附，所以，这种思路的数据库表结构设计从一开端即满足第三范式：一个表应满足第二范式，且属性间不存在传递依附。

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

(6)在映射后得出的数据库表结构中，应再根据第四范式进行进一步修正，确保不存在多值依附。这时，应根据反向工程的思路反馈给范畴模型。假如表结构中存在多值依附，则证实范畴模型中的对象具有至少两个以上的职责，应根据第一条进行设计修正。第四范式：一个表假如满足BCNF，不应存在多值依附。

(7)在经过火析后确认所有的表都满足二、三、四范式的情况下，表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调剂和重构。并且，我认为数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的，只是一个存储介质，所以，表和表之间也不利用强关联来表述业务（数据间的一致性），这一职责应由系统的逻辑层来保证，这种方法也确保了系统对于不准确数据（脏数据）的兼容性。当然，从全部系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据，单从另一个角度来说，脏数据的产生在必定程度上也是不可避免的，我们也要保证系统对这种情况的容错性。这是一个调和的计划。

(8)应针对所有表的主键和外键建立索引，有针对性的（针对一些大数据量和常用检索方法）建立组合属性的索引，提高检索效率。固然建立索引会耗费部分系统资源，但比拟起在检索时搜索整张表中的数据尤其时表中的数据量较大时所带来的性能影响，以及无索引时的排序把持所带来的性能影响，这种方法仍然是值得提倡的。

(9)尽量少采用存储过程，目前已经有很多技巧可以调换存储过程的功效如“对象/关系映射”等，将数据一致性的保证放在数据库中，无论对于版本把持、开发和安排、以及数据库的迁移都会带来很大的影响。但不可否定，存储过程具有性能上的上风，所以，当系统可应用的硬件不会得到晋升而性能又是非常重要的质量属性时，可经过平衡考虑选用存储过程。

(10)当处理表间的关联束缚所付出的代价（经常是应用性上的代价）超过了保证不会呈现修正、删除、更改异常所付出的代价，并且数据冗余也不是重要的标题时，表设计可以不符合四个范式。四个范式确保了不会呈现异常，但也可能由此导致过于纯粹的设计，使得表结构难于应用，所以在设计时需要进行综合判定，但首先确保符合四个范式，然后再进行精化修正是刚刚进进数据库设计范畴时可以采用的最好措施。

(11)设计出的表要具有较好的应用性，重要体现在查询时是否需要关联多张表且还需应用复杂的SQL技巧。

(12)设计出的表要尽可能减少数据冗余，确保数据的准确性，有效的把持冗余有助于提高数据库的性能。(义务编纂：卢兆林）