数据库重构

最新推荐文章于 2022-05-06 16:38:45 发布

cuad2192

最新推荐文章于 2022-05-06 16:38:45 发布

阅读量303

点赞数

文章标签：数据库驱动开发开发工具

《数据库重构》前言

演进式开发以及敏捷软件开发方法学，如极限编程（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等技术，创建了新的开发工具使这些技术变得更容易。我们实现了这些之后，意识到还需要一些技术和工具来支持演进式数据库开发。
以演进的方式进行数据库开发有以下好处：

将浪费减至最少。演进的、即时（JIT）的生产方式能够避免一些浪费，在串行式开发方式中，如果需求发生变化，这些浪费是不可避免的。如果后来发现某项需求不再需要，所有对详细需求、架构和设计工件方面的早期投资都会损失掉。如果有能力事先完成这部分工作，那肯定也有能力以JIT的方式来完成同样的工作。
避免了很多返工。在第1章将会看到，仍需要进行一些初始的建模工作，将主要问题前期想清楚，如果在项目后期才确定这些问题，可能会导致大量返工。你只是不需要很早涉及其中的细节。
总是知道系统可以工作。通过演进的方式，定期产生能够工作的软件，即使只是部署到一个演示环境中，它也能工作。如果每一两周就得到一个系统的可工作版本，就会大大地降低项目的风险。
总是知道数据库设计具有最高的品质。这就是数据库重构所关注的：每次改进一点schema设计。
与开发人员的工作方式一致。开发人员以演进的方式工作，如果数据专业人员希望成为现代开发团队中的有效成员，他们也需要以演进的方式工作。
减少了总工作量。以演进的方式工作，只需要完成今天真正需要完成的工作，没有其他工作。

演进式数据库开发也有一些不足之处：

存在文化上的阻碍。许多数据专业人员喜欢按串行式的方式进行软件开发，他们常持这样的观点：在编程开始之前，必须创建某种形式的详细逻辑和物理数据模型。现代方法学已经放弃了这种方式，因为它效率不高，风险较大，因此许多数据专业人员受到了冷遇。更糟糕的是，数据社区中的许多“思想领袖”是在20世纪70年代和80年代获得他们的初步经验的，但却错过了90年代的对象革命，因此没有取得演进式开发方面的经验。世界已经改变，而他们似乎没有跟着改变。读者会在本书中看到，数据专业人员不仅可能以演进的方式工作，实际上这也是比较可取的工作方式。
学习曲线。需要花时间来学习这些新技术，甚至需要花更多的时间将串行式的思维方式转变成演进式的思维方式。
工具支持还在发展之中。当《Refactoring》在1999年出版时，没有支持这一技术的工具。短短几年之后，每种集成开发环境（IDE）都内建支持代码重构的特征。在本书写作时，还没有数据库重构的工具，尽管我们在书中包含了手工实现重构所需的全部代码。幸运的是，Eclipse Data Tools Project（DTP）已经在他们的项目计划书中说明需要在Eclipse中开发数据库重构功能，所以工具厂商赶上来只是时间问题。

敏捷简介

虽然这不是一本专门讲述敏捷软件开发的图书，但实际上数据库重构是为敏捷开发者准备的主要技术。如果一个过程满足敏捷联盟（www.agilealliance.org）的4种价值观，它就被认为是敏捷的。这些价值观定义了一些偏好，而不是以某种方式取代另一种方式；鼓励关注特定领域，但并不排除其他领域。例如，过程和工具是重要的，但个人和他们之间的互动更重要。这4种敏捷价值观如下：

个人和他们之间的互动胜过过程和工具。需要考虑的最重要的因素是人以及他们如何一起工作；如果没有找对人，最好的工具和过程都会毫无用处。
工作的软件胜过面面俱到的文档。软件开发的主要目标是创建能工作的软件，满足项目涉众的要求。当然文档也有它的位置，编写得当的话，它能描述系统如何构建，为什么构建，以及如何利用系统工作。
顾客协作胜过合同谈判。只有顾客能告诉你他们想要什么。不幸的是，他们不擅长此道：他们可能缺少准确描述系统所需的技能，也可能一开始就没弄对，更糟的是，他们可能随着时间的推移而改变想法。与顾客签订合同是重要的，但合同不能代替有效的沟通。成功的IT专业人员会与他们的顾客密切协作，他们会投入一定的精力来发现顾客想要的东西，并一直教育他们的顾客。
响应变化胜过遵循计划。随着系统工作的推进，项目涉众对他们想要的东西的理解发生了变化，业务环境发生了变化，底层技术也发生了变化。变化是软件开发的现实，因此，你的项目计划和整体方式必须反映变化的环境，才能是有效的。

如何阅读本书

    本书的大部分内容(从第6章到第11章)包含了详细描述每一类重构的参考材料。前面5章描述了演进式数据库开发的基本思想和技术，特别介绍了数据库重构。读者应该依次阅读下面的章节：
    第1章“演进式数据库开发”，概述了演进式开发的基本思想和支持它的技术。综述了重构、数据库重构、数据库回归测试、通过AMDD方法进行演进式数据建模、数据库资产的配置管理，以及对独立的开发者沙盒的需求。
    第2章“数据库重构”，详细地探讨了数据库重构背后的概念，以及为什么它在实践中如此困难。展示了在“简单的”单应用环境下和复杂的多应用环境下数据库重构的例子。
    第3章“数据库重构过程”，描述了在简单和复杂的环境下，重构数据库schema所需的详细步骤。对于单应用数据库来说，你对环境拥有更大的控制力，因此重构schema所需的工作也要少得多。在多应用环境中，你需要支持一个转换期，在这段时间内数据库同时支持原来的schema和新的schema，让应用团队能更新他们的代码并将代码部署到生产环境中去。
    第4章“部署到生产环境”，描述了将数据库重构部署到生产环境中去的过程。这在多应用环境下特别富有挑战性，因为多个团队所做的改动必须合并和测试。
    第5章“数据库重构策略”，汇集了我们在这些年来发现的一些关于重构数据库schema的“最佳实践”。我们也提出了一些打算尝试但还没有机会尝试的想法。

致谢

我们想感谢这些人，他们为本书的编写提供了信息：Doug Barry、Gary Evans、Martin Fowler、Bernard Goodwin、Joshua Graham、Sven Gorts、David Hay、David Haertzen、Michelle Housely、Sriram Narayan、Paul Petralia、Sachin Rekhi、Andy Slocum、Brian Smith、Michael Thurston、Michael Vizdos和Greg Warren。
另外，Pramod想感谢Irfan Shah、Narayan Raman、Anishek Agarwal和其他团队成员，是他们经常对我的观点提出挑战，教给我许多软件开发的知识。我也感谢Martin给予我写作的机会，让我去演讲，积极参加ThoughtWorks之外的活动；感谢Kent Beck的鼓励，感谢我在ThoughtWorks的同事，他们在许多方面给予我帮助，让工作变得有趣；感谢我的父母Jinappa和Shobha，他们花了许多精力将我养育成人。

数据库重构.jpg