《数据库重构》读后感

数据库重构的分类

1. 结构重构：对一个或多个表或试图做一些变更。比如将一列从一个表移到另外一个表，将多用途的列拆分为一些单独的列。每个列用于单一用途。
2. 数据质量重构：一种变更，改进了数据库中所包含信息的质量。例如，不允许列为空，确保它总是有值，或对一列采用统一格式，确保一致性。
3. 参照完整性重构：一种变更，它确保参照的行在另外一个表的存在，并确保不需要的行被相应地删除。增加触发器支持两个实体间的层叠式删除。
4. 架构重构。一种变更，它从整体上改变了外部程序与数据库进行交互的方式。用存储过程取代部分代码和脚本。
5. 方法重构：对方法（存储过程、函数、触发器）的一种变更，改进方法质量，比如存储过程改名，把存储过程里面的*用相应的字段替换、、、、、
6. 替换：这不属于重构，转换时对数据Schema的一个变更，它改变了Schema的语义。

数据库味道

正如Flower在重构里面说的代码的坏味道一样，作者也尝试总结了一些数据库的坏味道。

1. 多用途的列。 如果一个列被用于多种用途，就有可能存在额外的代码来确保数据以“正确的方式”使用。个人认为像表里面用来判别性别、是否删除的字段这样的多用途列还不是坏味道，如果超出了两个应用，就应该考虑重构了。
2. 多用途的表。 如果一个表用来存放多种不同数据来源的数据。
3. 重复的数据。重复的数据对操作型数据库来说是一种严重的问题，因为数据存放在几个地方，不一致的机会就增加了。个人认为适当的冗余还是必须的。这个只能试情况而论。
4. 列太多的表。一个表包含太多的列时，说明表缺乏内聚——它试图存放来自几类实体的数据。我见过一个表几十个字段的设计，只能用“无语”来形容我的感受。
5. 行太多的表。大的表就有性能问题，查找就十分耗时，你这时就需要对表进行垂直分割：将一些列移到另外一个表，将一些行移到另外一个表，进行水平分割。
6. “智能”列：智能列是这样一种列，其中数据的不同位置代表了不同的概念。这个我不太了解（没有这方面的使用经验），作者的建议进行更小粒度的分割字段。
7. 害怕变化。如果你害怕改变你的数据库Schema，因为你担心更改会破坏其它很多应用程序，那么这就是一个明确的信号。

数据库重构在开发中的位置

作者提到了大多数面向数据技术本质上都是串行的。诸如逻辑数据建模或物理数据建模。希望数据库DBA采用类似开发者使用的现代演进式技术来开发，并能从中获益。作者提供了一幅图关于在一些关键开发活动中的高层视图，这些活动发生在涉及对象和关系数据库的现代项目中。请注意，所有的箭头都是双向的。你需要在这些活动之间来回迭代。同时注意没有定义起点和终点——显然这不是传统的串行式过程。