数据库重构(软件工程技术精选集)(第17届Jolt生产效率大奖获奖图书)
点击看大图基本信息
- 作者： (加)Scott W. Ambler Pramodkumar J.Sadalage [作译者介绍]
- 译者： 王海鹏
- 丛书名： 软件工程技术丛书
- 出版社：机械工业出版社
- ISBN：9787111346807
- 上架时间：2011-6-22
- 出版日期：2011 年6月
- 开本：16开
- 页码：219
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 综合
计算机 > 数据库 > 数据库理论 > 综合
编辑推荐
介绍数据库系统设计的强大重构技术 为数据库重构提供了全面的指导和参考
推荐阅读
内容简介回到顶部↑
作译者回到顶部↑
本书提供作译者介绍
Scott W. Ambler国际知名的软件过程改进顾问，技术领头人，敏捷建模、敏捷数据、企业统一过程、敏捷统一过程方法学的创始人。Scott经常在SoftwareDeveloPment、JavaOne、OOPSLA和DAMA等会议上进行主题演讲，他写作（或与他人合著）出版的书还包括《Agile Modeling》、《Agile DatabaseTeehnique》、《The Obieet Primer，Third Edition》、《The Elements of UML UML2.0 Style》和《The Enter Prise Unified Process》等。
Pramod J. Sadalage Thoughtworks公司的顾问。在1999年用XP方法开发一个大型J2EE应.. << 查看详细
Pramod J. Sadalage Thoughtworks公司的顾问。在1999年用XP方法开发一个大型J2EE应.. << 查看详细
目录回到顶部↑
《数据库重构》
对本书的赞誉
序
前言
致谢
第1章演进式数据库开发
1.1数据库重构
1.2演进式数据库建模
1.3数据库回归测试
1.4数据库工件的配置管理
1.5开发者沙盒
1.6演进式数据库开发技术的障碍
1.7本章小结
第2章数据库重构
2.1代码重构
2.2数据库重构
2.2.1单应用数据库环境
2.2.2多应用数据库环境
2.2.3保持语义
2.3数据库重构的分类
对本书的赞誉
序
前言
致谢
第1章演进式数据库开发
1.1数据库重构
1.2演进式数据库建模
1.3数据库回归测试
1.4数据库工件的配置管理
1.5开发者沙盒
1.6演进式数据库开发技术的障碍
1.7本章小结
第2章数据库重构
2.1代码重构
2.2数据库重构
2.2.1单应用数据库环境
2.2.2多应用数据库环境
2.2.3保持语义
2.3数据库重构的分类
前言回到顶部↑
演进式开发以及敏捷软件开发方法学，如极限编程（XP）、Scrum、Rational统一过程（RUP）、敏捷统一过程（AUP）和特征驱动开发（FDD），已经在过去几年中为信息技术（IT）产业带来了一场风暴。为了明确定义，演进式方法在本质上是迭代式和增量式的，敏捷方法在本质上是演进式和高度协作的。而且，像重构、结对编程、测试驱动开发（TDD）和敏捷模型驱动开发（AMDD）等敏捷技术也正在进入IT组织机构中。这些方法和技术已经形成，并在这些年里以草根的方式演进着，在实战中得到检验，而不是在象牙塔中形式化。简而言之，这些演进式开发和敏捷方法学似乎在实践中非常有效。
在Martin Fowler的开创性著作《Refactoring》中，他将重构描述为对源代码的一些小改动，这些改动会改进代码的设计，但不会改变其语义。换言之，你改进了工作的品质，但不会破坏或增加任何东西。在那本书中Martin提到，正如可以重构应用源代码一样，你也可能重构数据库schema(模式)。但是，他指出数据库重构相当困难，因为数据库中有相当程度的耦合，因此他选择不在他的书中讨论这部分内容。
自1999年《Refactoring》出版以来，我们俩发现了一些重构数据库schema的方法。开始，我们是独自工作的，在Software Development（www.sdexpo.com）等一些会议上见面，并通过邮件列表（www.agiledata.org/feedback.html）交流。我们讨论一些思想，参加对方的会议报告，很快发现彼此的思想和技术有着共同之处，并且相互吻合。所以我们合作编写了本书，分享我们在通过重构演进数据库schema方面的经验和技术。
本书中的示例代码是用Java、Hibernate和Oracle编写的。对于每一类数据库重构，描述时基本上都包含了修改数据库schema的代码；对于一些更有趣的重构，我们展示了它们对Java 应用代码所产生的影响。因为各种数据库并不一样，所以我们也讨论了当数据库产品之间存在重要差别时一些替代的实现策略。有时候，我们讨论一类重构的替代实现，这类重构使用了Oracle专有的特征，如SET UNUSED或RENAME TO等命令；我们的许多代码示例也用到了Oracle 的COMMENT ON特征。有些数据库包含另外一些使数据库重构变得容易的特征，好的DBA会知道如何利用这些特征。更好的是，将来数据库重构工具会为我们完成这些事情。而且，我们尽可能使Java代码保持简单，这样读者应该能够毫无困难地将这些代码转换成C#、C++或Visual Basic代码。
为何需要演进式数据库开发
演进式数据库开发是一个适时出现的概念。不是在项目的前期试图设计数据库schema，而是在整个项目生命周期中逐步地形成它，以反映项目涉众确定的不断变化的需求。不论你是否喜欢，需求会随着项目的推进而变化。传统的方式是忽略这个基本事实并试图以各种方式来“管理变更”，这实际上是对阻止变更的一种委婉的说法。现代开发技术的实践者们选择拥抱变化，并使用一些技术，从而能够随着需求的变化演进他们的工作。程序员们采用了TDD、重构和AMDD等技术，创建了新的开发工具使这些技术变得更容易。我们实现了这些之后，意识到还需要一些技术和工具来支持演进式数据库开发。
以演进的方式进行数据库开发有以下好处：
1.将浪费减至最少。演进的、即时（JIT）的生产方式能够避免一些浪费，在串行式开发方式中，如果需求发生变化，这些浪费是不可避免的。如果后来发现某项需求不再需要，所有对详细需求、架构和设计工件方面的早期投资都会损失掉。如果有能力事先完成这部分工作，那肯定也有能力以JIT的方式来完成同样的工作。
2.避免了很多返工。在第1章将会看到，仍需要进行一些初始的建模工作，将主要问题前期想清楚，如果在项目后期才确定这些问题，可能会导致大量返工。你只是不需要很早涉及其中的细节。
3.总是知道系统可以工作。通过演进的方式，定期产生能够工作的软件，即使只是部署到一个演示环境中，它也能工作。如果每一两周就得到一个系统的可工作版本，就会大大地降低项目的风险。
4.总是知道数据库设计具有最高的品质。这就是数据库重构所关注的：每次改进一点schema设计。
5.与开发人员的工作方式一致。开发人员以演进的方式工作，如果数据专业人员希望成为现代开发团队中的有效成员，他们也需要以演进的方式工作。
6.减少了总工作量。以演进的方式工作，只需要完成今天真正需要完成的工作，没有其他工作。
演进式数据库开发也有一些不足之处：
1.存在文化上的阻碍。许多数据专业人员喜欢按串行式的方式进行软件开发，他们常持这样的观点：在编程开始之前，必须创建某种形式的详细逻辑和物理数据模型。现代方法学已经放弃了这种方式，因为它效率不高，风险较大，因此许多数据专业人员受到了冷遇。更糟糕的是，数据社区中的许多“思想领袖”是在20世纪70年代和80年代获得他们的初步经验的，但却错过了90年代的对象革命，因此没有取得演进式开发方面的经验。世界已经改变，而他们似乎没有跟着改变。读者会在本书中看到，数据专业人员不仅可能以演进的方式工作，实际上这也是比较可取的工作方式。
2.学习曲线。需要花时间来学习这些新技术，甚至需要花更多的时间将串行式的思维方式转变成演进式的思维方式。
3.工具支持还在发展之中。当《Refactoring》在1999年出版时，没有支持这一技术的工具。短短几年之后，每种集成开发环境（IDE）都内建支持代码重构的特征。在本书写作时，还没有数据库重构的工具，尽管我们在书中包含了手工实现重构所需的全部代码。幸运的是，Eclipse Data Tools Project（DTP）已经在他们的项目计划书中说明需要在Eclipse中开发数据库重构功能，所以工具厂商赶上来只是时间问题。
敏捷简介
虽然这不是一本专门讲述敏捷软件开发的图书，但实际上数据库重构是为敏捷开发者准备的主要技术。如果一个过程满足敏捷联盟（wwwagileallianceorg）的4种价值观，它就被认为是敏捷的。这些价值观定义了一些偏好，而不是以某种方式取代另一种方式；鼓励关注特定领域，但并不排除其他领域。例如，过程和工具是重要的，但个人和他们之间的互动更重要。这4种敏捷价值观如下：
1.个人和他们之间的互动胜过过程和工具。需要考虑的最重要的因素是人以及他们如何一起工作；如果没有找对人，最好的工具和过程都会毫无用处。
在Martin Fowler的开创性著作《Refactoring》中，他将重构描述为对源代码的一些小改动，这些改动会改进代码的设计，但不会改变其语义。换言之，你改进了工作的品质，但不会破坏或增加任何东西。在那本书中Martin提到，正如可以重构应用源代码一样，你也可能重构数据库schema(模式)。但是，他指出数据库重构相当困难，因为数据库中有相当程度的耦合，因此他选择不在他的书中讨论这部分内容。
自1999年《Refactoring》出版以来，我们俩发现了一些重构数据库schema的方法。开始，我们是独自工作的，在Software Development（www.sdexpo.com）等一些会议上见面，并通过邮件列表（www.agiledata.org/feedback.html）交流。我们讨论一些思想，参加对方的会议报告，很快发现彼此的思想和技术有着共同之处，并且相互吻合。所以我们合作编写了本书，分享我们在通过重构演进数据库schema方面的经验和技术。
本书中的示例代码是用Java、Hibernate和Oracle编写的。对于每一类数据库重构，描述时基本上都包含了修改数据库schema的代码；对于一些更有趣的重构，我们展示了它们对Java 应用代码所产生的影响。因为各种数据库并不一样，所以我们也讨论了当数据库产品之间存在重要差别时一些替代的实现策略。有时候，我们讨论一类重构的替代实现，这类重构使用了Oracle专有的特征，如SET UNUSED或RENAME TO等命令；我们的许多代码示例也用到了Oracle 的COMMENT ON特征。有些数据库包含另外一些使数据库重构变得容易的特征，好的DBA会知道如何利用这些特征。更好的是，将来数据库重构工具会为我们完成这些事情。而且，我们尽可能使Java代码保持简单，这样读者应该能够毫无困难地将这些代码转换成C#、C++或Visual Basic代码。
为何需要演进式数据库开发
演进式数据库开发是一个适时出现的概念。不是在项目的前期试图设计数据库schema，而是在整个项目生命周期中逐步地形成它，以反映项目涉众确定的不断变化的需求。不论你是否喜欢，需求会随着项目的推进而变化。传统的方式是忽略这个基本事实并试图以各种方式来“管理变更”，这实际上是对阻止变更的一种委婉的说法。现代开发技术的实践者们选择拥抱变化，并使用一些技术，从而能够随着需求的变化演进他们的工作。程序员们采用了TDD、重构和AMDD等技术，创建了新的开发工具使这些技术变得更容易。我们实现了这些之后，意识到还需要一些技术和工具来支持演进式数据库开发。
以演进的方式进行数据库开发有以下好处：
1.将浪费减至最少。演进的、即时（JIT）的生产方式能够避免一些浪费，在串行式开发方式中，如果需求发生变化，这些浪费是不可避免的。如果后来发现某项需求不再需要，所有对详细需求、架构和设计工件方面的早期投资都会损失掉。如果有能力事先完成这部分工作，那肯定也有能力以JIT的方式来完成同样的工作。
2.避免了很多返工。在第1章将会看到，仍需要进行一些初始的建模工作，将主要问题前期想清楚，如果在项目后期才确定这些问题，可能会导致大量返工。你只是不需要很早涉及其中的细节。
3.总是知道系统可以工作。通过演进的方式，定期产生能够工作的软件，即使只是部署到一个演示环境中，它也能工作。如果每一两周就得到一个系统的可工作版本，就会大大地降低项目的风险。
4.总是知道数据库设计具有最高的品质。这就是数据库重构所关注的：每次改进一点schema设计。
5.与开发人员的工作方式一致。开发人员以演进的方式工作，如果数据专业人员希望成为现代开发团队中的有效成员，他们也需要以演进的方式工作。
6.减少了总工作量。以演进的方式工作，只需要完成今天真正需要完成的工作，没有其他工作。
演进式数据库开发也有一些不足之处：
1.存在文化上的阻碍。许多数据专业人员喜欢按串行式的方式进行软件开发，他们常持这样的观点：在编程开始之前，必须创建某种形式的详细逻辑和物理数据模型。现代方法学已经放弃了这种方式，因为它效率不高，风险较大，因此许多数据专业人员受到了冷遇。更糟糕的是，数据社区中的许多“思想领袖”是在20世纪70年代和80年代获得他们的初步经验的，但却错过了90年代的对象革命，因此没有取得演进式开发方面的经验。世界已经改变，而他们似乎没有跟着改变。读者会在本书中看到，数据专业人员不仅可能以演进的方式工作，实际上这也是比较可取的工作方式。
2.学习曲线。需要花时间来学习这些新技术，甚至需要花更多的时间将串行式的思维方式转变成演进式的思维方式。
3.工具支持还在发展之中。当《Refactoring》在1999年出版时，没有支持这一技术的工具。短短几年之后，每种集成开发环境（IDE）都内建支持代码重构的特征。在本书写作时，还没有数据库重构的工具，尽管我们在书中包含了手工实现重构所需的全部代码。幸运的是，Eclipse Data Tools Project（DTP）已经在他们的项目计划书中说明需要在Eclipse中开发数据库重构功能，所以工具厂商赶上来只是时间问题。
敏捷简介
虽然这不是一本专门讲述敏捷软件开发的图书，但实际上数据库重构是为敏捷开发者准备的主要技术。如果一个过程满足敏捷联盟（wwwagileallianceorg）的4种价值观，它就被认为是敏捷的。这些价值观定义了一些偏好，而不是以某种方式取代另一种方式；鼓励关注特定领域，但并不排除其他领域。例如，过程和工具是重要的，但个人和他们之间的互动更重要。这4种敏捷价值观如下：
1.个人和他们之间的互动胜过过程和工具。需要考虑的最重要的因素是人以及他们如何一起工作；如果没有找对人，最好的工具和过程都会毫无用处。
序言回到顶部↑
10年前，重构(refactoring)还是一个只有少数人知道的词，主要用在Smalltalk社区。很高兴看到越来越多的人开始学习通过重构以一种训练有素和有效的方式来修改工作代码。许多人现在将代码重构视为软件开发的一个基本组成部分。
我的工作领域是企业应用开发，而企业应用开发的一个很大的部分就是与数据库打交道。在我最初关于重构的书籍中，我就已经指出了数据库是重构的一个主要问题领域，因为重构数据库会引入一些新的问题。在企业软件开发领域中，数据库专业人员与软件开发人员之间隔了一堵因互不理解和相互竞争所形成的墙，这个可悲的隔阂使得这些问题变得恶化。
我喜欢Scott和Pramod的一个原因是，他们以不同的方式努力工作，试图打破这种隔阂。Scott在其关于数据库的著作中一贯地尝试跨越这一鸿沟，他在对象关系映射方面的工作极大地影响了我关于企业应用架构的写作。Pramod可能名气小一些，但他对我的影响同样很大。当我们在ThoughtWorks一起做一个项目时，我们被告知重构数据库是不可能的。Pramod不同意这种看法，他产生了一些粗略的想法，并把这些想法变成了一种训练有素的计划，让数据库schema(模式)保持在一种稳定但受控的变化中。这使得应用开发人员能够在代码中自由地进行演进式设计。自那时起，Pramod将这些技术带给了我们的许多客户，并在ThoughtWorks的同事中传播这些技术，至少对我们来说，使数据库不再成为持续设计的拦路石。
本书汇集了两个人的经验，他们工作于应用与数据之间的无人地带，提供了对数据库重构的技术指导。如果你熟悉重构，你会注意到主要变化是你必须管理持续的数据迁移，而不只是改变程序和数据的结构。本书告诉了你如何进行数据迁移，其背后是两位作者积累的项目经验（和教训）。
尽管我很高兴看到本书出版，但我希望这只是第一步。在我的关于重构的书出版之后，我很高兴地看到出现了一些成熟的工具，利用这些工具能自动完成许多重构任务。我希望同样的情况也出现在数据库上，我们也看到一些供应商开始提供这方面的工具，使持续的schema和数据迁移变得更加容易。在这一切发生之前，本书将帮助你构建自己的过程和工具；以后，本书作为成功使用这类工具的基础，仍将体现其价值。
——Martin Fowler，《企业应用架构模式》等畅销书作者，ThoughtWorks首席科学家
自我开始软件开发生涯以来，行业和技术的许多方面都已发生了巨大的变化。但没有改变的是软件开发的基础本质。创造软件从来都不难——只需要一台计算机并开始大量地产出代码。但创造良好的软件却很难，而创建优秀的软件更是难上加难。这种情形直至今天也没有改变。今天，我们可以更容易地创建更大、更复杂的软件系统，只需将不同来源的一些部件拼凑在一起。软件开发工具得到了极大的发展，我们对创建软件的过程中哪些有效、哪些无效也有了更多的认识。然而大多数软件仍然是脆弱的，并努力想达到可接受的品质。或许是因为我们正在创建更大、更复杂的系统，或许是因为我们使用的技术仍然存在某些基本的缺失。由于前面两个因素，我相信今天的软件开发会像以前一样富有挑战性。幸运的是，新的技术不断出现，为我们提供了帮助。在这些进展中，能够极大地影响我们在项目开始时认识其潜在能力的却极少。重构所涉及的技术，以及相关的敏捷方法学，就是这些少有的进展之一。本书所包含的工作在一个很重要的方向上扩展了这一基础。
重构是一种受控的技术，指安全地改进代码的设计而不改变它的行为语义。任合人都可能有机会改进代码，但重构带来一种训练有素的方法，能安全地进行改动（通过测试），并利用软件开发社区所积累的知识（通过重构）。自从Fowler推出了这个领域的开创性书籍以来，重构已经被广泛地应用，帮助检测重构的可能性和对代码进行重构的工具也已被广泛采用。然而在应用的数据层，重构却被证实要困难得多。部分问题无疑是文化上的原因，正如这本书所展示的；但是同时也缺少适用于数据层的清晰的过程和一组重构技术。这相当不幸，因为数据层的糟糕设计几乎总是会带来更高层的问题，通常会引起一连串的坏设计，而这只是为了徒劳地维护这个不可靠基础的稳定性。而且，不能演进数据层，不论是因为忽视了这一点或者是害怕改变，都将妨碍所有依赖于它的工作，最终导致不能交付最好的软件。正是这些问题使得这项工作变得很重要：我们现在有了一个过程和一组重构技术，使我们能在这个重要的领域进行迭代式设计改进。
我很高兴看到这本书的出版，希望它能推动创造一些工具来支持书中描述的技术。软件行业目前处于一个有趣的阶段，我们看到了开放源代码软件的兴起以及它所带来的协作工具。在像Eclipse Data Tools Platform这样的项目中，人们自然希望在工具中实现数据库重构。我希望开源社区努力工作来实现这一愿景，因为潜在的回报是巨大的。如果数据库重构像一般的重构那样得到广泛采用，软件开发将变得更加成熟。
——John Graham，Eclipse Data Tools Platform项目管理委员会主席，Sybase公司高级工程师
数据社区在许多方面错过了整个敏捷软件开发革命。应用开发者已广泛应用重构、测试驱动开发以及其他技术，使迭代成为有效的高级软件开发方式；而数据专业人士却在很大程度上忽略了这些潮流，甚至把自己与潮流隔离开来。
当我还在一家大型金融服务机构做应用开发时，就清楚地看到了这一点。那时我的办公室就在开发团队和数据库团队之间。我很快发现，尽管他们之间只有几步之遥，但两个团队的文化、实践和过程是极为不同的。顾客的要求对开发团队来说就意味着一些重构，代码检入(check in)，以及迅速的验收测试。对数据库团队而言，类似的请求就意味着正式的变更请求，要通过层层批准，最后才能开始修改schema。这种繁杂的过程开销常常使开发人员和顾客变得沮丧，但事情只能这样，因为数据库团队不知道能有什么其他办法。
然而，如果他们的业务想在今天不断发生变化的竞争环境中得到发展，那么，他们就必须学习其他的办法。数据社区必须像开发者那样采用一些敏捷技术。
本书是一本无价的资源，它向数据专业人士展示了怎样实现飞越，自信而安全地拥抱变化。Scott和Pramod展示了小的、迭代式重构的设计改进如何使敏捷DBA避免大的前期设计错误，以及如何随着对顾客需求理解的逐步加深与应用一起演进数据库schema。
不要弄错，重构数据库是很难的。即使是像列改名这样的简单变化，都会引起schema、相关对象、持久层框架和应用层的相应改变，这令DBA觉得重构似乎是一种不可用的技术。
本书列出了一组实践说明，向专业DBA展示了如何将敏捷方法用于数据库的设计和开发。Scott和Pramod对实现每类数据库重构的详细描述证明了它是可行的，为数据库广泛采用重构铺平了道路。
因此，我建议数据专业人士行动起来。阅读这本书，拥抱变化，广为宣传。数据库重构是改进数据社区敏捷性的关键。
——Sachin Rekhi，微软公司项目经理
在系统开发的世界里，存在两种不同的文化：一种是由面向对象（OO）开发者主宰的，他们在Java和敏捷软件开发中自由呼吸；另一种由关系数据库人员主宰，他们喜欢仔细的工程方法和稳定的关系数据库设计。这两个阵营说着不同的语言，参加不同的会议，相互之间似乎很少交谈。这种分裂在许多组织机构的IT部门中得到了反映。OO开发人员抱怨DBA们古板而保守，不能跟上快速变化的节奏。数据库专业人士哀叹Java开发人员的愚蠢行为，因为他们不知道怎样和数据库打交道。
Scott Ambler和Pramod Sadalage属于能够跨越两种文化的很少的一部分人。本书是从OO架构师的角度来谈数据库设计的；因此，本书对于OO开发人员和关系数据库专业人员都有价值。它帮助OO开发人员在数据库领域应用敏捷代码重构技术，并让关系数据库专业人员了解OO架构师的想法。
我的工作领域是企业应用开发，而企业应用开发的一个很大的部分就是与数据库打交道。在我最初关于重构的书籍中，我就已经指出了数据库是重构的一个主要问题领域，因为重构数据库会引入一些新的问题。在企业软件开发领域中，数据库专业人员与软件开发人员之间隔了一堵因互不理解和相互竞争所形成的墙，这个可悲的隔阂使得这些问题变得恶化。
我喜欢Scott和Pramod的一个原因是，他们以不同的方式努力工作，试图打破这种隔阂。Scott在其关于数据库的著作中一贯地尝试跨越这一鸿沟，他在对象关系映射方面的工作极大地影响了我关于企业应用架构的写作。Pramod可能名气小一些，但他对我的影响同样很大。当我们在ThoughtWorks一起做一个项目时，我们被告知重构数据库是不可能的。Pramod不同意这种看法，他产生了一些粗略的想法，并把这些想法变成了一种训练有素的计划，让数据库schema(模式)保持在一种稳定但受控的变化中。这使得应用开发人员能够在代码中自由地进行演进式设计。自那时起，Pramod将这些技术带给了我们的许多客户，并在ThoughtWorks的同事中传播这些技术，至少对我们来说，使数据库不再成为持续设计的拦路石。
本书汇集了两个人的经验，他们工作于应用与数据之间的无人地带，提供了对数据库重构的技术指导。如果你熟悉重构，你会注意到主要变化是你必须管理持续的数据迁移，而不只是改变程序和数据的结构。本书告诉了你如何进行数据迁移，其背后是两位作者积累的项目经验（和教训）。
尽管我很高兴看到本书出版，但我希望这只是第一步。在我的关于重构的书出版之后，我很高兴地看到出现了一些成熟的工具，利用这些工具能自动完成许多重构任务。我希望同样的情况也出现在数据库上，我们也看到一些供应商开始提供这方面的工具，使持续的schema和数据迁移变得更加容易。在这一切发生之前，本书将帮助你构建自己的过程和工具；以后，本书作为成功使用这类工具的基础，仍将体现其价值。
——Martin Fowler，《企业应用架构模式》等畅销书作者，ThoughtWorks首席科学家
自我开始软件开发生涯以来，行业和技术的许多方面都已发生了巨大的变化。但没有改变的是软件开发的基础本质。创造软件从来都不难——只需要一台计算机并开始大量地产出代码。但创造良好的软件却很难，而创建优秀的软件更是难上加难。这种情形直至今天也没有改变。今天，我们可以更容易地创建更大、更复杂的软件系统，只需将不同来源的一些部件拼凑在一起。软件开发工具得到了极大的发展，我们对创建软件的过程中哪些有效、哪些无效也有了更多的认识。然而大多数软件仍然是脆弱的，并努力想达到可接受的品质。或许是因为我们正在创建更大、更复杂的系统，或许是因为我们使用的技术仍然存在某些基本的缺失。由于前面两个因素，我相信今天的软件开发会像以前一样富有挑战性。幸运的是，新的技术不断出现，为我们提供了帮助。在这些进展中，能够极大地影响我们在项目开始时认识其潜在能力的却极少。重构所涉及的技术，以及相关的敏捷方法学，就是这些少有的进展之一。本书所包含的工作在一个很重要的方向上扩展了这一基础。
重构是一种受控的技术，指安全地改进代码的设计而不改变它的行为语义。任合人都可能有机会改进代码，但重构带来一种训练有素的方法，能安全地进行改动（通过测试），并利用软件开发社区所积累的知识（通过重构）。自从Fowler推出了这个领域的开创性书籍以来，重构已经被广泛地应用，帮助检测重构的可能性和对代码进行重构的工具也已被广泛采用。然而在应用的数据层，重构却被证实要困难得多。部分问题无疑是文化上的原因，正如这本书所展示的；但是同时也缺少适用于数据层的清晰的过程和一组重构技术。这相当不幸，因为数据层的糟糕设计几乎总是会带来更高层的问题，通常会引起一连串的坏设计，而这只是为了徒劳地维护这个不可靠基础的稳定性。而且，不能演进数据层，不论是因为忽视了这一点或者是害怕改变，都将妨碍所有依赖于它的工作，最终导致不能交付最好的软件。正是这些问题使得这项工作变得很重要：我们现在有了一个过程和一组重构技术，使我们能在这个重要的领域进行迭代式设计改进。
我很高兴看到这本书的出版，希望它能推动创造一些工具来支持书中描述的技术。软件行业目前处于一个有趣的阶段，我们看到了开放源代码软件的兴起以及它所带来的协作工具。在像Eclipse Data Tools Platform这样的项目中，人们自然希望在工具中实现数据库重构。我希望开源社区努力工作来实现这一愿景，因为潜在的回报是巨大的。如果数据库重构像一般的重构那样得到广泛采用，软件开发将变得更加成熟。
——John Graham，Eclipse Data Tools Platform项目管理委员会主席，Sybase公司高级工程师
数据社区在许多方面错过了整个敏捷软件开发革命。应用开发者已广泛应用重构、测试驱动开发以及其他技术，使迭代成为有效的高级软件开发方式；而数据专业人士却在很大程度上忽略了这些潮流，甚至把自己与潮流隔离开来。
当我还在一家大型金融服务机构做应用开发时，就清楚地看到了这一点。那时我的办公室就在开发团队和数据库团队之间。我很快发现，尽管他们之间只有几步之遥，但两个团队的文化、实践和过程是极为不同的。顾客的要求对开发团队来说就意味着一些重构，代码检入(check in)，以及迅速的验收测试。对数据库团队而言，类似的请求就意味着正式的变更请求，要通过层层批准，最后才能开始修改schema。这种繁杂的过程开销常常使开发人员和顾客变得沮丧，但事情只能这样，因为数据库团队不知道能有什么其他办法。
然而，如果他们的业务想在今天不断发生变化的竞争环境中得到发展，那么，他们就必须学习其他的办法。数据社区必须像开发者那样采用一些敏捷技术。
本书是一本无价的资源，它向数据专业人士展示了怎样实现飞越，自信而安全地拥抱变化。Scott和Pramod展示了小的、迭代式重构的设计改进如何使敏捷DBA避免大的前期设计错误，以及如何随着对顾客需求理解的逐步加深与应用一起演进数据库schema。
不要弄错，重构数据库是很难的。即使是像列改名这样的简单变化，都会引起schema、相关对象、持久层框架和应用层的相应改变，这令DBA觉得重构似乎是一种不可用的技术。
本书列出了一组实践说明，向专业DBA展示了如何将敏捷方法用于数据库的设计和开发。Scott和Pramod对实现每类数据库重构的详细描述证明了它是可行的，为数据库广泛采用重构铺平了道路。
因此，我建议数据专业人士行动起来。阅读这本书，拥抱变化，广为宣传。数据库重构是改进数据社区敏捷性的关键。
——Sachin Rekhi，微软公司项目经理
在系统开发的世界里，存在两种不同的文化：一种是由面向对象（OO）开发者主宰的，他们在Java和敏捷软件开发中自由呼吸；另一种由关系数据库人员主宰，他们喜欢仔细的工程方法和稳定的关系数据库设计。这两个阵营说着不同的语言，参加不同的会议，相互之间似乎很少交谈。这种分裂在许多组织机构的IT部门中得到了反映。OO开发人员抱怨DBA们古板而保守，不能跟上快速变化的节奏。数据库专业人士哀叹Java开发人员的愚蠢行为，因为他们不知道怎样和数据库打交道。
Scott Ambler和Pramod Sadalage属于能够跨越两种文化的很少的一部分人。本书是从OO架构师的角度来谈数据库设计的；因此，本书对于OO开发人员和关系数据库专业人员都有价值。它帮助OO开发人员在数据库领域应用敏捷代码重构技术，并让关系数据库专业人员了解OO架构师的想法。
媒体评论回到顶部↑
“这本突破性的《数据库重构》向我们揭示了为什么数据库schema(模式)不一定难以改变，为什么数据不一定难以迁移，以及为什么数据库专业人员不一定要被来自顾客和开发者的变更请求压得喘不过气来。演进式设计是敏捷的核心。Ambler和Sadalage向大家展示了如何演进敏捷的数据库。漂亮！”
——Joshua Kerievsky，Industrial Logic公司的创始人，
《Refactoring to Patterns》一书的作者
“《数据库重构》不仅提供了演进式数据库开发的基础知识，还提供了许多实际的、详细的数据库重构的例子。对于对敏捷开发感兴趣的数据库专业人员来说，这是一本必读的好书。”
——Doug Barry，Barry & Associates公司的总裁，
《Web Services and ServiceOriented Architectures: The Savvy Managers Guide》一书的作者
“Ambler和Sadalage朝着别的作者觉得棘手的问题迈出了勇敢的一步。他们不仅关注数据库重构背后的理论，还解释了一步一步的过程，以一种受控的、深思熟虑的方式来进行数据库重构。但真正征服我的是超过200页的代码示例和深入的技术细节，展示了如何解决具体的数据库重构问题。这不仅是一本介绍一种好思想的书——更是一本教程和技术参考书，开发人员和DBA都会将它放在计算机旁。荣誉归于两位作者，他们成功地完成了其他人甚至都不敢尝试的事情。”
——Kevin Aguanno，IBM加拿大公司高级项目经理
“任何承担真实项目的人都会认识到Scott和Pramod通过本书给软件开发生命周期带来的价值。与原有数据库打交道是一件相当麻烦的事情。尽管许多挑战可能是文化上的，改进可能被强势的DBA策略所忽略，但本书展示了重构和演进式数据库开发在技术上如何能够真正地以敏捷的方式进行。我希望遇到下一位坏心情的DBA时，将这本书放在他的桌上。”
——Jon Kern
“《数据库重构》很出色。它很适合数据专业人士，这些人需要在敏捷开发和对象技术的世界中完成他们的工作。通过精心组织，本书展示了什么是数据库重构，为什么要进行数据库重构以及如何进行数据库重构，同时也展示了相关的代码。就像一本最好的菜谱，我会在开发和改进数据库时经常用到它。”
——David R. Haertzen，First Place Software公司数据管理中心的编辑
“这本优秀的图书带来了在数据世界的重构敏捷实践。它提供了实际的指导，包括在机构中重构数据库的方法学，以及如何实现单次重构的细节。这本书也阐述了开发者与DBA互相协作的重要性；是开发者和DBA必备的一本参考图书。”
——Per Kroll，IBM RUP开发经理，Eclipse Process Framework项目负责人
“Scott和Pramod对数据库重构所做的事相当于Martin Fowler对代码重构所做的事。他们提供了一组一致的过程，你可以用这些过程来改进数据库的质量。如果你要与数据打交道，《数据库重构》就是为你写的。”
——Ken Pugh，《Prefactoring》一书的作者
“现在是数据人员加入敏捷行列的时候了，Ambler和Sadalage正是合适的领头人。数据建模者、管理员以及软件团队都应该读这本书。长期以来我们在不同的技术世界里各行其是，本书将有助于消除我们之间的隔阂。”
——Gary K. Evans，敏捷过程传道者，Evanetics公司
“演进式设计和重构已经令人很兴奋了，有了重构数据库后就更妙了。在这本书中，作者与我们分享了在数据库层面进行重构的技术与策略。通过这些重构，即使是数据库已经部署到生产环境中，数据库schema也可以安全地演进。通过本书，数据库就能被所有开发者访问。”
——Sven Gorts
——Joshua Kerievsky，Industrial Logic公司的创始人，
《Refactoring to Patterns》一书的作者
“《数据库重构》不仅提供了演进式数据库开发的基础知识，还提供了许多实际的、详细的数据库重构的例子。对于对敏捷开发感兴趣的数据库专业人员来说，这是一本必读的好书。”
——Doug Barry，Barry & Associates公司的总裁，
《Web Services and ServiceOriented Architectures: The Savvy Managers Guide》一书的作者
“Ambler和Sadalage朝着别的作者觉得棘手的问题迈出了勇敢的一步。他们不仅关注数据库重构背后的理论，还解释了一步一步的过程，以一种受控的、深思熟虑的方式来进行数据库重构。但真正征服我的是超过200页的代码示例和深入的技术细节，展示了如何解决具体的数据库重构问题。这不仅是一本介绍一种好思想的书——更是一本教程和技术参考书，开发人员和DBA都会将它放在计算机旁。荣誉归于两位作者，他们成功地完成了其他人甚至都不敢尝试的事情。”
——Kevin Aguanno，IBM加拿大公司高级项目经理
“任何承担真实项目的人都会认识到Scott和Pramod通过本书给软件开发生命周期带来的价值。与原有数据库打交道是一件相当麻烦的事情。尽管许多挑战可能是文化上的，改进可能被强势的DBA策略所忽略，但本书展示了重构和演进式数据库开发在技术上如何能够真正地以敏捷的方式进行。我希望遇到下一位坏心情的DBA时，将这本书放在他的桌上。”
——Jon Kern
“《数据库重构》很出色。它很适合数据专业人士，这些人需要在敏捷开发和对象技术的世界中完成他们的工作。通过精心组织，本书展示了什么是数据库重构，为什么要进行数据库重构以及如何进行数据库重构，同时也展示了相关的代码。就像一本最好的菜谱，我会在开发和改进数据库时经常用到它。”
——David R. Haertzen，First Place Software公司数据管理中心的编辑
“这本优秀的图书带来了在数据世界的重构敏捷实践。它提供了实际的指导，包括在机构中重构数据库的方法学，以及如何实现单次重构的细节。这本书也阐述了开发者与DBA互相协作的重要性；是开发者和DBA必备的一本参考图书。”
——Per Kroll，IBM RUP开发经理，Eclipse Process Framework项目负责人
“Scott和Pramod对数据库重构所做的事相当于Martin Fowler对代码重构所做的事。他们提供了一组一致的过程，你可以用这些过程来改进数据库的质量。如果你要与数据打交道，《数据库重构》就是为你写的。”
——Ken Pugh，《Prefactoring》一书的作者
“现在是数据人员加入敏捷行列的时候了，Ambler和Sadalage正是合适的领头人。数据建模者、管理员以及软件团队都应该读这本书。长期以来我们在不同的技术世界里各行其是，本书将有助于消除我们之间的隔阂。”
——Gary K. Evans，敏捷过程传道者，Evanetics公司
“演进式设计和重构已经令人很兴奋了，有了重构数据库后就更妙了。在这本书中，作者与我们分享了在数据库层面进行重构的技术与策略。通过这些重构，即使是数据库已经部署到生产环境中，数据库schema也可以安全地演进。通过本书，数据库就能被所有开发者访问。”
——Sven Gorts
加载中...
