Rails 迁移 重新思考数据库模式变化

欢迎进入Java社区论坛，与200万技术人员互动交流 >>进入 Ruby on Rails 是不断发展的 Web 开发框架，它实现了一些先进的想法，例如通过配置进行约定、大量的元编程、特定于域的语言以及用数据库包装代替对象关系映射。这篇文章研究的 Rails 模式迁移是一种把

欢迎进入Java社区论坛，与200万技术人员互动交流 >>进入

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

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

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

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

　　这篇文章深入研究了 Ruby on Rails 迁移 ―― Rails 处理生产数据库变化的解决方案。迁移用包装的方式组合了协调模式变化和数据变化的威力和简单性。（如果以前没有学习过活动记录 ―― Rails 底层的持久性层，我建议您先阅读 跨越边界 系列中以前的这篇 Rails 文章 .）

[1] [2] [3] [4] [5] [6]