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

    RD：对于这种方法我突然想到两个问题：首先，存在数据重复的问题。从某种意义上说，来自老系统的数据将需要移植–合并入–新系统中的数据，而新系统同时也在积累新的数据。某些老系统中的数据可能已经失效。

   Scott：在我们的书中我们显示了如何解决这个问题，因此这不是个问题。每一个重构示例包括实施重构的代码，包含数据移植代码，还有如何移除老的模式和保持数据同步的支持代码。

   RD：第二个问题：如果你针对每一个新版本进行一个升级模式，而每隔几个星期就会有新版本发布的话，随着时间的发展，会不会堆积很多不同的模式？跟踪每一个应用程序或每个应用程序的每一个版本所使用的模式，这对维护来说可能是一件非常麻烦的事情。

   Scott：实际上这不是什么问题。如果你非常频繁的发布新版本的话，每一个版本的中修改肯定非常小。如果一个重构覆盖了前一个重构，例如你将字段X先修改为Y，后又修改为Z，你可以轻松的修改你的过度期方案来反映这一点。尽管这种方法不完美，但是如果你能保持敏捷的话，也可以降低它的复杂性。在书中我们还讨论了采取敏捷模型驱动（AMDD）方法，它可以降低重大重构所带来的风险。

   现有的数据库开发工具也会具有重大的完善。在未来几年中，随着演进的数据库设计（EDD）的普及，我们会更好的工具在商业和开源领域中出现。

   正如我前面所说的，数据库重构是技术上的一个尝试，真正的挑战在文化的障碍上。数年前，数据库界认为演进的数据库设计实现起来非常困难，现在已经开始努力去了解如何可以换实现它。我们还需要做更多的工作来让现有的数据库从业人士认同它，并克服长期以来一直存在的在数据库界“思想领袖”指导下的许多错误看法。

   RD：当应用到一个实际系统中的时候，在你的书中描述的一些重构方法可能并不适用。举个例子来说，“Introduce Common Format”表示对一个现有表字段中的所有数值应用一个统一的格式，它的目的是简化外部编程代码。对于重构一个实际系统中的这些问题，难道不是面向对象数据访问层更适合来做的事情吗？

   Scott：为了实施这种重构，你需要选择一个已经被这个字段所支持的格式。例如，如果有7种不同的格式，选择这些格式中的一种，因为所有的访问系统必须已经能够处理它们。下一步是清空所有已有的数值，将它们使用共同的格式。你还需要准备好相应的编程准备，例如数据库触发器，它可以确保对这个字段的任何更新能够以同一种格式完成。在过渡期，你应该让这个触发器保持工作；直到访问系统被更新到以共同的格式来写到字段中。

   对一个数据库的压缩访问无疑是有好处的，因为它减少了对你的数据库模式的耦合，这也是我们在书中讨论的一部分内容。但是，假若某些系统不经过你的公共访问层，会发生什么？如果你有一些COBOL系统，一些C++系统，一些Java系统和一些APL系统，它们访问相同的数据库，会发生什么呢？直觉告诉我它们不会使用相同的面向对象数据访问层。

   RD：你的书中提到的许多重构方法都涉及到应用触发器来确保数据一致性。那么，数据库重构有别于代码重构，在某种意义上说，代码修改是“绝对的”，替代以前运行的代码，然而数据库重构积累下很多触发器。你认为这是一个问题吗？

   Scott：这就是为什么需要过渡期的原因。在过渡期结束的时候，你需要移除老的模式和任何支持性的触发器。这样的话，这些相关补丁只存在一段时间。如果你不移除它们的话，将会发生问题。通过脚本来清理这些运行的触发器是非常简单的，为了方便我们的读者，我们在书中为每一个重构都提供了这种脚本的示例。

   RD：当然，还有一种风险，所有这些触发器将可能对系统带来影响，例如使数据库变慢。