循序渐进讲授数据表的102个设计原则

核心提示：数据表的设计原则: 1)不应针对全部系统进行数据库设计，而应当根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，假设不同组件间的表需要外键关联也尽可能不要创建外键关联，而只是记录

数据表的设计原则:

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

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

(3)根据建立的领域模型进行数据库表的映照，此时应参考数据库设计第2范式：1个表中的所有非关键字属性都依托于全部关键字。关键字可以是1个属性，也能够是多个属性的集合，不论那种方式，都应确保关键字能够保证唯1性。在肯定关键字时，应保证关键字不会参与业务且不会出现更新异常，这时候，最优解决方案为采取1个自增数值型属性或1个随机字符串作为表的关键字。

(4)由于第1点所述的领域模型驱动的方式设计数据库表结构，领域模型中的每1个对象只有1项职责，所以对象中的数据项不存在传递依托，所以，这类思路的数据库表结构设计从1开始即满足第3范式：1个表应满足第2范式，且属性间不存在传递依托。

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

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

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

(8)应针对所有表的主键和外键建立索引，有针对性的（针对1些大数据量和常常使用检索方式）建立组合属性的索引，进步检索效率。固然建立索引会消耗部份系统资源，但比较起在检索时搜索整张表中的数据特别时表中的数据量较大时所带来的性能影响，和无索引时的排序操纵所带来的性能影响，这类方式依然是值得提倡的。

(9)尽可能少采取存储进程，目前已有很多技术可以替换存储进程的功能如“对象/关系映照”等，将数据1致性的保证放在数据库中，不管对版本控制、开发和部署、和数据库的迁移都会带来很大的影响。但不可否认，存储进程具有性能上的上风，所以，当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性时，可经过平衡考虑选用存储进程。

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

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

(12)设计出的表要尽可能减少数据冗余，确保数据的正确性，有效的控制冗余有助于进步数据库的性能。(责任编辑：卢兆林）

评论加载中... 内容： 评论者： 验证码：