《数据库重构》读书笔记
作者：臭豆腐[trydofor.com]
日期：2010-04-27
授权：署名-非商业-保持一致 1.0 协议
声明：拷贝、分发、呈现和表演本作品，请保留以上全部信息。
文档目录
1. 倒序的读后感
最后写的读后感总是在最前，这样可以最快浮现整体的印象。
书不厚，累计耗时3,4天，却拖了一个半月。
作者啰嗦点，译者外行点，豆腐从咬文嚼字到走马观花。
豆腐太需要数据和数据库重构了，因为：
-
表的字段太多，200,300的那么多。
-
每两周一次发布都有schema的更新，不限于改数据，增字段，换类型，变主键。
-
冗余数据多，条条大道通罗马，好是不好。
-
表很多，主表400余，辅表亦然。
-
数据小海量，上亿，上十G。基本垂直优化到了尽头。
数据和数据库重构，基本上都是组合拳，牵涉到所有角色。
书中是分节动作，总结起来就是做事6要素：
首先What，Why，How，然后Where，When，最后安排Who。
2. 正文前的唠叨
【2010-04-27】
数据库重构/机械工业出版社/ISBN7-111-20209-0/32元。
Refactoring Database Evolutionary Database Design
在Credit，司空见惯的是Schema改变和数据迁移。
也许本书能有新的答案，或引起思考。
【赞誉】光环效应，比较流行。适合学习如何表示赞叹。
【序】四个人写了序，头衔不小，可惜一个也不认识。
【前言】“关于封面”原版的确是桥，中文版却弄个“烟灰缸”。
【致谢】很人性，但TMD没“感谢国家”。
3. 第一章 演进式数据库开发
【引言】瀑布是美妙的旅游景点。但用来组织软件开发项目，
瀑布式却是一种特别差劲的策略。-- Scott Ambler。
【P1|P1】演进式的，以迭代和增量方式工作，软件过程，方法学。
【BTW】RUP,XP,Scrum,DSDM,水晶方法,TSP,AUP,EUP,FDD,RAD都没用过 :(
【P1|P2】有效协同工作的方法，白板 > 电话 > EMail > 详细文档。
【C1.1】代码重构，保持行为语义，DB重构要保持行为和信息语义。
【C1.2】JIT(Just In Time) 即时生产，够用就行。
【C1.3|T】TFD(Test First Development)编写代码前必须写一个会失败的测试。
【C1.3|B】TDD是TFD和重构的结合。
【C1.4】DB重构前准备工作。按部就班。
【C1.5】图1.5 为用户提供安全性的逻辑沙盒。
【C1.6】障碍是文化最大，工具其次。
4. 第二章 数据库重构
【引言】一旦你冻结了设计，他就开始变得过时。-- Fred Brooks
【C2.1】现在的代码是否是最好的设计，使我能够加入新特征。先重构在加新。
【C2.2.1】单应用的重构过程：人员结对，旧测试成功，新测试失败，移动列，
重构程序，新测试成功，旧测试失败，旧测试重构，旧测试成功。
备份数据，复制列，测试成功，删除列，测试成功。
【C2.2.2】多应用的重构过程：过程同单应用，但转换期内，新旧并存并同步数据。
【P12|B】信息语义只从信息使用者角度，数据库中信息的意义。
【P13|M】行为语义目标是保持黑盒功能性不变。
【C2.4】DB坏味：多用途列/表；重复数据；列太多；行太多；智能列；害怕变化。
【C2.6】耦合不会降到0，但肯定会到受管理的程度。
5. 第三章 数据库重构过程
【引言】
新的科学真理不是通过说服它的对手并让他们看到光明而取得胜利的，而是因为
它的对手最终死去，新成长起来的一代熟悉新的科学真理。-- Max Planck
【P20】迭代活动列表及流程图，注意回归测试和版本控制。
【C3.1】与DBA一起思考，重构的意义，必要性，代价。一次做一个，做好。
【C3.2】转换和重构，数据源。分析并理解问题，识别问题的多个方面。
【C3.3】转换期内，新旧共存，可达几季度或几年，比较恐怖。
【C3.4】SQLUnit java的。前，中，后测试，必要时进行回归测试。
【C3.5】Schema的版本。
【C3.6】设计越清晰，就越少需要文档。
【C3.7-C3.11】罗列了一次过程，视乎有点啰嗦。
6. 第四章 部署到生成环境
【引言】如果我们不改变方向，不久就会到达我们想去的地方。-- Dr. Irwin Corey
【C4.1】沙盒：开发（经常）--项目集成（受控）--生成前（高受控)--生成
【C4.4】部署过程图，这个还行。
【BTW】前四章，比较墨迹，各小节标题的概括性很高。
7. 第五章 数据库重构策略
【2010-05-18】
【引言】今天比昨天知道得多是今天的好消息，而不是昨天的坏消息。-- Ron Jeffries
【C5.1】原子级的小变更，步步为营。
【C5.2】唯一标识策略：FIFO，UUID，其他标识。
【C5.4】DB标识DB(DB配置表)。UPDATE DatabaseConfiguration SET SchemaVersion=17;
【C5.5】schema 同步策略：trigger,view,program的优缺点。
【C5.6】个人觉得：计划周详，应该缩短转换期，而不是长。
【C5.7】成了委员会，一起研究。
【C5.9-C5.12】管理好脚本（SQL等）
【C5.13】政治斗争,囧。还好Credit没这东西。
【C5.15】www.agiledata.org
【BTW】这一章，领启的很好，信息量足。
8. 第六章 结构重构
【BTW】跨过前面的场景铺垫，现在开始摆弄刀法。
【C6.1】常见问题：触发器死循环。
发现和修复，视图，触发器，存储过程，耦合表（隐式耦合）。
确定转换期。
【C6.2】删除列
【P45】临时表；海量数据(SET UNUSED)；外键处理，视图封装表。
【P46】以防万一，保存主键和删除列 Create Table ... as select ...
【P47】演示代码，仅仅演示，不要使用。
【C6.3】删除表：数据完整性。（这是个什么样的场景呢）
【C6.4】删视图：视图常常伴随着安全访问控制。最小公分母法
【C6.5】引入计算列：同步策略，定期批处理或数据源触发器。确定源数据。
【C6.6】引入替代键：减少耦合，增加一致性，改进性能。
【P53|B】自然键(natural key)于替代键(surrogate key）之争是个“宗教信仰问题”。
【P54|T】自然键关联业务。替代键简化键策略和业务耦合。
【P55-P56】图6.5和代码比较清晰。
【C6.7】合并列：粒度，精度，用途评估。
【C6.8】合并表：似合并列，起因为，过度设计，信息不对称。
【C6.9】移动列，起于规范或性能。确定删除，插入规则，增加新列，同步数据。
【C6.10】列改名，可读性，移植性。
【C6.11】表改名：RENAME+VIEW 或 新旧表+同步。
【C6.12】视图改名：基于新视图重建旧视图。
【C6.13】用表取代大对象(LOB)：元数据拆分，如住址分省市区。
【C6.14】取代普通列：类型变化等。
【C6.15】关系表取代一对多关系：过渡到多对多，但增加连接数，影响性能。
【C6.16】自然键取代替代键：减少开销，统一键策略，删除不必要键。
【C6.17】拆分列：细粒度化，避免多用途列。
【C6.18】拆分表(垂直拆分)：性能改进，1NF要求，安全控制。
9. 第七章 数据质量重构
【2010-06-07】
【C7.1】常见问题：修复约束，视图，存储过程；更新数据（行锁，表锁）。
【C7.2】增加查找列：为一个列创建一个查找表。
【C7.3】采用标准代码：统一列里的代码(code)值，保证数据库内类似列的一致。
【C7.4】采用标准类型：保证列类型与数据库内其他类似列一致。
【C7.5】统一主键策略：为一个实体选择一个键策略，并在数据库中保持一致。
【C7.6】删除列约束：过时的列约束。
【C7.7】删除缺省值：对已存在数据是否变更。
【C7.8】删除NOTNULL约束：是否可用缺省值。
【C7.9】引入列约束：有效性检查。
【C7.10】引入通用格式：对表内已有数据采用一致的格式。
【C7.11】引入缺省值：参考C7.12
【C7.12】使列不可空：改变已有列，使其 NOT NULL
【C7.13】移动数据：所有列或部分列的数据移动另外一个表。
【C7.14】用属性标识取代类型代码：滥表达，貌似是Value变Code。
10. 第八章 参照完整性重构
【C8.1】增加外键约束：强制实现到另一个表的关系。
【C8.1|T】外键约束降低了DB性能，每更新是会对另一个表进行验证，索引。
【P129|B】立即检查-注意顺序/延迟检查-提交事务时。
【C8.2】为计算列增加触发器：是应用程序完成，还是数据库完成（有效更新）。
【C8.3】删除外键约束：性能和质量折衷，可以DISABLE外键，保持关系但不检查。
【C8.4】引入层叠删除：CASCADE是级联删除！！外行翻译。
【C8.5】引入硬删除：记录标记为删除（软）和真正删除记录（硬）
【C8.6】引入软删除：列标记，标识删除，叫做软删除或逻辑删除。
【C8.7】为历史数据引入触发器：为保存历史数据或审计的目的。LOG*表。
11. 第九章 架构重构
【C9】改变外部程序与DB交互的方式。
【C9.1】增加CRUD方法：增查改删。但存储过程，函数，触发器，依赖厂商不易移植。
【C9.2】增加镜像表：精确复制另一个数据库中的已有表。远程变本地，同步策略。
【C9.3】增加读取方法：参考 C9.1。
【C9.4】用视图封装表：实现外观(Facade)或安全访问(SAC)。DB视图和表的支持。
【C9.5】引入计算方法：通常是存储函数。可改进应用性能，取代计算列，统一算法。
【C9.6】增加索引：索引(唯一或非唯一)。改善查询性能，但修改性能下降。
【C9.7】引入只读表：只读。
【C9.8】从数据库中移除方法：存储过程，函数，触发器挪到应用程序中。
【C9.9】将方法移至数据库：反C9.8。
【C9.10】用视图取代方法：基于原有的DB方法（存储过程...）创建视图。
【C9.11】用方法取代视图：反 C9.10。
【C9.12】使用正式数据源：多源时，用最official的数据源。
12. 第十章 方法重构
【C10】"Refactoring重构"一书，把程序代码重构引入到DB的方法重构。
【C10.1】接口变更重构。
【C10.1.1】增加参数。
【C10.1.2】方法参数化：合并多个方法变成参数控制行为。
【C10.1.3】删除参数：过时的，不正确的，容易误用的，Cut之。
【C10.1.4】方法改名：名之。
【C10.1.5】参数重排序：按靠谱的顺序排列。
【C10.1.6】用明确的方法取代参数：参数多到混乱时。
【C10.2】内部重构，改进方法实现的质量，保持接口和行为不变。
【C10.2.1】合并条件表达式：if if 变 and or。
【C10.2.2】分解条件：方法调用代替条件判断。
【C10.2.3】提取方法：代码片段变方法。
【C10.2.4】引入变量：命名好复杂表达式的各项式。
【C10.2.5】删除控制标记：各种flag。
【C10.2.6】消除中间人：间接调用变直接。
【C10.2.7】参数改名：间接调用变直接。
【C10.2.8】用表查找取代文字常量：重构中取代魔数和符号常量的数据库版本。
【C10.2.9】用条件短语取代嵌套条件：IF-IF-IF变成 IF-END，IF-END。
【C10.2.10】拆分临时变量：多功能临时变量。
【C10.2.11】替换算法。
13. 第十一章 转换
【C11】为Schema增加新特性，改变语义。
【C11.1】插入数据：在原表中插入数据。
【C11.2】引入新列：在原表中引入新列。
【C11.3】引入新表：略。
【C11.4】引入视图：基于原有表建视图。
【C11.5】更新数据：╮(╯▽╰)╭。
14. 附录和词汇表
【P203】UML表示法。统一交流方式，小有用途。
【P207】词汇表。装X必备，译者基本上没在文中列出使用位置。
回复 刘松 2010年07月09日 星期五 13:33
不过，可以用来做为参考。
顺便打个广告：欢迎加入MySQL群http: