数据库表结构设计方法及原则

数据库设计的三大范式：为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。

　　在实际开发中最为常见的设计范式有三个：第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式；第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中；第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。总结一下，就是：第一范式(确保每列保持原子性)；第二范式(确保表中的每列都和主键相关)；第三范式(确保每列都和主键列直接相关,而不是间接相关)。

　　在目前的企业信息系统中，数据库还是最佳的数据存储方式，虽然已经有很多的书籍在指导我们进行数据库设计，但应该那种方式是设计数据库的表结构的最好方法、设计时应遵从什么样的原则、四个范式如何能够用一种方式达到顺畅的应用等是我一直在思考和总结的问题，下文是我针对这几个问题根据自己的设计经历准备总结的一篇文章的提纲，欢迎大家一块进行探讨，集思广益。其中提到了领域建模的概念，但未作详细解释，希望以后能够有时间我们针对这个命题进行深入探讨。

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

//注意他这里说的是"不要创建外键关联"，创建外键关联的语句是：//foreign key(member_id) references member (id);//我们几乎没有用到这条语句，因为我们就是这样做的，用到外键时，只是记录关联表的主键，而非在数据库级别上创建外键。//也不知道是歪打正着，还是前辈DBA过于强大，已经考虑好了。

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

// 领域模型驱动的方式，目前用的还不是很熟，考虑的不够多。因为经常的数据库中的表只是拿来做存储用而已，//特别是小需求，要加什么字段，找到相关表加上去就行了，不太考虑领域模型。这个在中文站老业务表里很常见

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

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

//数据库三范式记不得的同学去查资料温习一下。//个人认为第三范式的目的是尽量减少数据冗余，保证相同的数据只存在一份。//第三范式其实我们遵守的并不是很严格，特别是老的数据库表中会有冗余字段。这个要看情况决定吧。

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

//最后一句看不懂，可能是"所以表及表关联关系不应该出现删除和插入异常。"？

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

//第四范式我们遵守的并不多吧。//例如：//VAS_WP_CONFIG.config_name字段的值包括：adv（广告主题）/glare（炫彩滚动主题）/theme_simple（普通主题）/theme_cartoon（动画主题）/ theme_none（不显示背景主题）//cate_background（类目背景）/video（公司视频）/board_cartoon（动画招牌）/board_simple（普通招牌）等。//如果遵守第四范式，则需要新增一张VAS_WP_CONFIG_NAME表，存储配置名称枚举值，而VAS_WP_CONFIG.config_name字段改为VAS_WP_CONFIG.config_name_id。//这样做更利于扩展，不会因为每个人的理解不一致而向VAS_WP_CONFIG.config_name字段里设置乱七八糟的值，但是这样需要维护更多的小表，造成数据值表的数量膨胀，DBA可能会觉得管理上有更多的困难。//我们采用潜规则约定、java枚举类等其它方式来进行保证。但有时候效果并不是很好，经常发现旧数据库表中枚举字段的值五花八门，不全是约定的。

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

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

//索引目前都是DBA根据具体的SQL来创建的，不过开发写SQL时，也应该适当考虑一下字段的索引。

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

//目前都是杜绝使用存储过程的，我觉得用起来比较方便，对于我们来说，主要原因是会给DBA带来管理方面的麻烦，//因为时间一长，存储过程的逻辑和使用场景，往往没人能了解，容易产生更多问题

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

11.设计出的表要具有较好的使用性，主要体现在查询时是否需要关联多张表且还需使用复杂的SQL技巧。我感觉遵守的范式越多，就越使SQL复杂，具体情况具体分析。设计出的表要尽可能减少数据冗余，确保数据的准确性，有效的控制冗余有助于提高数据库的性能

　　因此，考虑了以上条件之后，表设计约定规则如下：

//规则1:表必须要有主键。//规则2:一个字段只表示一个含义。//规则3:总是包含两个日期字段:gmt_create(创建日期),gmt_modified(修改日期)，且这两个字段不应该包含有额外的业务逻辑。//规则4:MySQL中，gmt_create、gmt_modified使用DATETIME类型。//规则5:禁止使用复杂数据类型（数组，自定义类型等）。//规则6: MySQL中，附属表拆分后，附属表id与主表id保持一致。不允许在附属表新增主键字段。//规则7: MySQL中，存在过期概念的表，在其设计之初就必须有过期机制，且有明确的过期时间。过期数据必须迁移至历史表中。//规则8: MySQL中，不再使用的表，必须通知DBA予以更名归档。//规则9: MySQL中，线上表中若有不再使用的字段，为保证数据完整，禁止删除。//规则10: MySQL中，禁止使用OCI驱动，全部使用THI驱动。