我们必须文档化不同的数据库重构，因此我们还不能详细描述他们。然而这里有几点需要指出：像代码重构一样，数据库重构非常微小；概念链一系列微小的变化，数据库和代码很相似；变化的三个属性使保持小的变化更加重要。

　　许多数据库重构，如增加一个字段，可以不必更新所有存取系统的代码来完成。但是如果在使用新计划之前并不了解它，该字段将会无用，因为新计划不知道其变化之处。许多变化，没有考虑整个系统计划，我们称之为破坏性变化，如将一个已经存在的空值列设置为非空。破坏性变化需要多加留心，留心的程度依赖于包含破坏性的程度。一个小破坏性的例子是将一个已经存在的空值列设置为非空，在这种情况下你可以蒙着头做。

　　而重构将考虑数据库中空值数据，开发人员将更新数据库映射代码，因此更新不会破坏其它人的代码；如果偶然会破坏，开发人员将在建立和使用测试时发现问题。

　　将一个经常使用的表分成两个是一种更复杂的破坏。在这种情况中提前让所有人知道变化到来很重要，这样他们可以有所准备。此外应该在一个更安全的时刻来实施变化。这里面很重要的一点是选择适用于你做出的变化的过程。

　　3.6 自动重构

　　在代码世界中许多语言能够实现自动重构。在计划变化和数据迁移过程中，这种自动化对于数据库也非常重要。因此每个数据库重构都可以通过编写SQL DDL（对于计划变化）和DML（对于数据迁移）来完成。这些变化不是通过手工实现，而是通过一些SQL语句来自动实现变化。

　　一旦完成代码，我们保存这些代码文件来产生数据库变化的完整的变化记录，作为数据库重构的结果。我们于是可以更新任何实例到新的主数据库，通过运行在我们拷贝主数据库来产生更早的数据库实例的变化记录。

　　自动化变化的序列化是对于持续集成和迁移产品数据库的一个基本功能。

　　为了后产品数据库我们并不在常规迭代周期中实施变化，我们在每一个发布之间建立完整的数据库重构变化日志。毫无疑问，这是一个巨大的变化，我们必须离线实施该变化，在实际应用之前先测试迁移计划是明智之举。迄今为止，这项技术相当管用，通过将大变化分解为小的简单的变化，我们可以对产品数据进行大的变化，同时又不会给我们太多的麻烦。套用兵法中的一句话，是“化整为零”。

　　除了自动化向前的变化，我们也要考虑重构时向后的变化，如果能够做到这样可以回到以前的数据库状态。在我们的项目中并没有这样做，因为没有这个需求，但这同样是很重要的基本原则。

　　3.7 自动地更新所有开发人员的数据库

　　人们变化和更新主数据库，但是如何发现主数据库已经发生变化？在传统的持续集成有源代码的环境中，开发人员在提交变化之前先更新主数据库。这样他们可以在提交变化给共享主数据库之前，解决他们自己的机器上的问题。

　　每次主数据库发生改变时，我们都要更新开发人员的数据库。当主数据库发生变化时，我们自动化更新所有项目成员的数据库。相同的重构代码更新主数据库上的同时，自动更新成员数据库。也许有人认为在开发人员不知情的情况下，更新开发人员数据库会产生很多问题，但在实践中我们没发现什么问题。当然，这只在人们联网时管用。所以当开发人员离线时，必须尽快与主数据库重新保持同步。

　　3.8 清晰地分离所有的数据库获取代码

　　为了理解数据库重构的结果，了解应用程序如何使用数据库也非常重要。如果SQL语句分布在代码基础周围，则很难这样去做。因此一个清晰的数据库获取层很重要，它用来显示数据库如何被使用，在哪里被使用。

　　清晰的数据库层有很多好处。它减少了开发人员操纵数据库时需要使用SQL知识的地方，这样使对SQL语句不太熟悉的开发人员更易开发。对于DBA来说，给他提供了清晰的代码，可以清楚地了解数据库将如何使用。这也帮助准备索引、数据库优化，优化SQL语句，使DBA更好地理解数据库如何被使用。

　　4 变化法则

　　如同任何实践一样，这些原则必须根据你特殊的环境变化。没有一成不变的项目，我们必须要应对变化。

　　4.1 保持多个数据库在一个系统中

　　简单项目也许只需要一个主数据库。但是复杂项目需要有多个数据库，即数据库系。如果在投入生产之前数据库必须分支，那么我们可以创建新的数据库系。数据库系类似于代码的分支，需要不同测试数据集来进行测试。

　　当开发人员从主数据库中获取了一份拷贝，必须注册他们在修改哪个数据库系。当DBA更新主数据库某个数据库系时，同时更新了所有注册这个数据库系的开发人员的数据库。