数据库重构『英文版』读后的个人总结

一，在敏捷开发中，当用户story进入开发阶段时，首先是判断现有代码是否能够完成用户的story。重构，将会伴随整个的开发过程。重构在保持原有的行为语义不变的基础上,采用渐进地（演进式）方式，逐步实现代码结构的渐进式地优化。并且在这个渐进的过程中，采用回归测试的方式，以保持语义的不变性。而数据库重构不仅要保持行为语义的不变，还要保持信息语义的不变。我们在进行数据库重构的时候, 需要由项目的集成环境提交到生产环境中, 在发布的过度期里，需要旧的schema和新的schema并行存在，但是呢,又不能造成数据信息重复和丢失，我们可以通过”结构代码” 粘合在一起, 以确保信息语义的一致性。例如使用触发器，在旧表和新表之间保持信息语义的不变。
二，如果应用程序的现有代码结构不合理，就需要重构现有的代码。要重构，就必须先了解代码的语义。最好局部和全局的区分，语义也有重点, 在重构的过程中，尽量去掉“坏味道”，应用程序有坏味道，数据库的设计也有坏味道，主要是 多义表，多字段表, 多记录表, 含义不明确的字段等。在数据库重构时，对于多记录表，可以做垂直切分和水平切分 如何做切分，应该主要根据数据的不同的特性和字段间关系做区分。
三，在做数据库重构时，要注意外围扩展程序的重构。通过小地，聚焦地，渐进式地，持续不断地重构, 使数据库的外围的程序的结构得到不断的优化。回归测试，要尽可能的自动化。但是在进行数据库重构的时候，要注意数据的迁移。
四，在数据库的重构中，每一次的脚本变化，都可以放在类似于stack的一个模型中，在管理脚本变化的过程中，可以把过期的脚本从statck中去掉，最终的脚本变化，可以捆绑到每一次的发布中，这样或许我们可以看到每个版本的数据库的脚本的变化的分布情况，从开发环境中发布到生产环境中，需要有计划的，可以在系统活动不频繁的时间进行发布。
五，计算字段的选择，如何选择计算字段，采用触发器的方式，保持数据的同步。过多的联合主键，会影响数据的性能，可以采用替代主键，没有实际的业务含义，但可以保持一定的数据库的性能,也可以和业务实体保持一致。自然键也可以保留，以支持查询。在外键关联表中，自然键可以删除
六，在数据库的设计中，有lob型的字段，有可能是保存的比较复杂的数据结构，在程序中处理是比较复杂的，可以尝试在一个表中的多个字段，或者是一个新表来重构原来的表,这样程序的复杂度将会降低。当然，反之，我们重新解析lob型数据的时候，程序在逻辑上有可能会复杂一些
七，一对多的关系，是多对多关系的子集。在一对多关联的两表之间，建立关系表，可以为后来的多对多关系的重构做好调整
八，拆分字段，这样信息会更明确一点,要先添加字段。然后做数据的同步。保持数据库的信息语义的一致。要更新外围代码，数据库持久层的改动，拆分表, 把重复数据拆分出一个独立的表， 提高查询的性能, 把一些查询频率不是很高的clob型的字段拆分出一个独立的表，把访问权限不一样的字段拆分出一个单独的表
九，为了保证数据的质量，数据完整性的约束，非空的约束,主外键的约束