重构数据库：演进的数据库设计

   演进的数据库设计（Evolutionary Database Design，EDD，又叫数据库重构）是当今软件开发世界中一个颇具争议的话题。这是一个刺痛很多数据库管理员DBA的话题，因为它推动了对包含实时客户数据的数据库模式的改变，有时候甚至是多个应用程序使用同一个数据库。

   考虑到这个争论性的话题，以及在许多数据库专家对重复技术的抵制，似乎将其中一些公共的批评意见与《重构数据库：演进的数据库设计》一书的作者之一Scott Ambler进行探讨，是一件非常有意义的事情。

   Scott W．Ambler，国际知名的软件过程改进顾问，技术领头人，敏捷建模、敏捷数据、企业统一过程、敏捷统一过程方法学的创始人。Scott经常在Software DeveloPment、JavaOne、OOPSLA和DAMA等会议上进行主题演讲，他写作（或与人合著）出版的书还包括《Agile Modeling》、《Agile DatabaseTeehnique》、《The Obieet Primer，ThirdEdition》、《The Elements of UML UML 2.0 Style》和《TheEnterPrise Unified Process》等。

   RD：你好，Scott。首先，请你告诉我们为什么你认为数据库设计需要一个演进式的方法？

   Scott：大家首要知道的是，数据库没有什么特殊的地方。就如同设计工作方面的演进式方法也可以非常好的适合软件开发的其他方面一样，它们对数据库也同样如此。正如Pramod和我在《重构数据库》一书中所指出的一样，它实际上是使现有的关系数据库模型发展的一个技术上的尝试，甚至可以让数百个不同的系统来访问它。

   不幸的是，传统数据库社区的人们认为改进数据库模式是一件非常难的事情，因此从来不去考虑如何来实现它。更糟糕的是，这种看法导致了一些其他方面人们的疑问，诸如是否需要一个描述系统早期数据方面信息的建模。最终的结果是，许多数据专业人士未能理解今天应用程序开发者认为理所当然的一些基本的原理和技术。他们必须要做很多工作来弥补这个差距。

   RD：就某种意义上来说，这个数据库模式是问题领域的一种反思：只要它经过详细的设计，一旦设计好后，它通常不应该再需要改变太多，当然，这个设计也是来自于客户、终端用户、业务分析师等之间的共同努力而产生的。考虑到这些原因，在软件开发领域真的需要演进的数据库设计吗？

   Scott：我将拿现有的数据库产品的状况来说明这一点。多长时间你会发现数据库的表中具有不再被使用的字段？或者有些表的字段是否被用于好几种用途，因为这个表增加需要的字段已经非常困难；或者发现有存在数据质量问题的表？数据仓库协会（EDWI）几年前曾表示，在美国企业中，数据质量问题每年所带来的损失高达6110亿美元。这个结论告诉我们，实际上我们在前期的设计工作上做的并不完美， 对数据库的需求实际上是随着时间而变化的。事实已经非常明白的说明，企业需要一个安全的方式来修正已有的数据库问题，而在重构数据库中体现的方法只是其中的选择之一。数据库设计的传统方法明显已经被证明不能解决我们所面对的问题。

   RD：你是否把数据库重构看作被应用到细节开发中的一种方法？就像测试驱动设计（TDD）技术一样。因此你要开始一个测试，创建一个表，然后再编写另一个测试，增加一个字段、一个约束等等？

   Scott：当然，事实上我已经在2007年发布的IEEE软件上发表了一篇文章来专门介绍这个话题。

   RD：在此之前，我与一些数据库管理员和开发者进行了交流；发现有个频发困扰他们的主要问题，当你将一个系统投入生产后，然后做出修改的话，需要方案进行升级或数据移植；这种情况每隔几个星期都会发生。

  Scott：这就是为什么人们需要阅读《重构数据库》一书的原因。首先，你在开发者沙盒（sandbox）开发和测试你的修改，只有当你相信这种修改没问题后，你才能进入更高级别的沙盒（sandbox）进行测试。直接针对一个真实的数据库进行开发很明显是一个非常冒险的做法，因此不要那么做。

   其次，正如TDWI数据所显示的那样，你实际上需要一个可行的策略来扩展一个现有的产品数据库。这种策略就是需要一个过渡期，即原有的数据库模式和修正后的模式应该并行运行一段时间，数据库自动保持更新。这个期限可能是几个月也可能是几年，目的是给访问系统的开发团队时间来更新他们的系统，并部署新设计到产品中。

   一旦系统被更新，老模式就被移除。在《重构数据库》一书中，我们提供了解决方案，包含利用这种方法进行的60多个重构实例的完整源代码。