Ruby on Rails 是不断发展的 Web 开发框架，它实现了一些先进的想法，例如通过配置进行约定、大量的元编程、特定于域的语言以及用数据库包装代替对象关系映射。这篇文章研究的 Rails 模式迁移是一种把每个数据库的模式变化与基本对象模型分离的思想。

　　作为喜欢冒险的摩托车手，我关注两个严肃的社区:山地摩托车手和公路摩托车手。常规的看法是山地摩托车手更危险，但我并不同意。公路摩托手必须考虑要比石头和树危险得多的障碍:汽车。类似的异议也出现在面向对象应用程序开发使用的两个持久性策略之间。

　　目前，持久性框架使用两种方法中的一种: 映射 或 包装 。映射解决方案允许创建独立的数据库模式和对象模型，然后用一个软件层来管理两者间的差异。映射解决方案试图构建一个与数据库模式的结构非常相似的对象模型。与之相反，包装解决方案用对象作为数据库表和行的包装器来操纵数据库中的数据。常规的想法认为在解决方案发布之后，映射解决方案通常更灵活，因为映射软件能够更好地处理模式或对象模型中的变化。但是这个想法忽略了其中最重要的部分:数据。要有效地管理涉及持久性域模型的应用程序变化，必须协调数据、模式和模型的变化。大多数项目团队做不到这一点。

　　开发团队处理模式变化时，通常会用 SQL 脚本从头开始生成一个新版模式。脚本可能会删除所有的表，再添加所有的表。这样的策略会破坏所有测试数据，因此对于生产场景来说毫无价值。偶尔，工具可能会创建脚本，由脚本生成 delta 模式，或者生成使用 alter_table 这样的 SQL 命令修改以前版本的模式。但是很少有团队会费力气创建能取消模式变化的脚本，而且成功地创建了处理数据变化的自动脚本的团队更少。简而言之，传统的映射策略忽略公路上的汽车:回退坏的模式变化并处理数据。

　　这篇文章深入研究了 Ruby on Rails 迁移 —— Rails 处理生产数据库变化的解决方案。迁移用包装的方式组合了协调模式变化和数据变化的威力和简单性 。

　　在 Java 编程中处理模式变化

　　基于映射的框架需要模式、模型和映射。这样的框架是重复性的。请想像一下指定一个属性需要重复多少次:

• 　　模型中的 getter
• 　　模型中的 setter
• 　　模型中的实例变量
• 　　映射的 “to” 端
• 　　映射的 “from” 端
• 　　列定义

　　公平地讲，Hibernate 这样的 Java 框架通过代码生成的方式消除了不少重复工作。对象关系映射器可以处理遗留模式，对于新的数据库模式，可以用 Hibernate 提供的工具直接从模型生成模式并用 IDE 生成 getter 和 setter。可以用 Java 标注把映射嵌入域模型，但是按我的观点，这在一定程度上违背了使用映射的初衷。这种代码生成技术还有另一个用途:模式迁移。有些代码生成工具可以发现新的域模型和旧的模式之间的区别，并生成沟通这些不同的 SQL 脚本。请记住这些脚本处理的是模式，而不是数据。

　　例如，考虑这样一个迁移:把 first_name 和 last_name 这两个数据库列合并成叫作 name 的单一列。来自典型 Java 持久性框架的工具对数据库管理员没有帮助，因为这些工具只处理问题的一部分:模式中的变化。在进行这个模式变化时，还需要能够处理现有数据。在需要部署这个假想应用程序的新版本时，数据库管理员通常必须手工创建 SQL 脚本来完成以下工作:

• 　　创建叫作 name 的新列。
• 　　把 first_name 和 last_name 的数据放到新列中。
• 　　删除 first_name 和 last_name 列。

　　如果造成模式变化的代码版本仍然处在不完善的状态，那么经常必须手工回退变化。只有很少的团队有这个素养可以集成并自动进行跨模型、模式和数据的变化。