为什么使用数据库迁移而不是版本控制的模式

迁移无疑比仅仅启动phpMyAdmin和更改架构更好(就像我在php时期所做的那样),但在使用它们一段时间后,我认为它们存在致命缺陷.

版本控制是一个已解决的问题.迁移的主要功能是保留数据库更改的历史记录.但是为每次更改存储不同的文件是一种笨拙的方式来跟踪它们.如果post.rb要添加新的虚拟属性,则不要创建新版本(或表示增量的文件) - 当您要添加新的非虚拟属性时,为什么要创建新的迁移？

换句话说,就像检查post.rb版本控制一样,为什么不检查schema.rb到版本控制并直接对文件进行更改？

这在功能上与为每个delta保留文件相同,但使用起来要容易得多.我的心理模型是"我希望表X有这样的列(或者我真的希望模型X具有这样的属性)" - 为什么你必须从这里推断如何从现有的模式中获得; 只是打开schema.rb并给表X正确的列!

但即使是类包装表的想法也是一个实现细节!为什么我不能打开post.rb并说:

 Class Post
    t.string :title
    t.text :body
 end

如果你使用这样的模型,你必须决定如何处理现有数据.但即便如此,迁移也是过度的 - 当您迁移数据时,当您使用迁移down方法时,您将失去保真度.

无论如何,我的问题是,即使你想不出一个更好的方法,也不是有点粗略的迁移？

为什么不检查schema.rb到版本控制并直接对文件进行更改？

因为数据库本身与版本控制不同步.

例如,您可能正在使用源树的头部.但是,您要连接到已定义为过去版本的数据库,而不是您已签出的版本.迁移允许您逐步升级或降级数据库架构从任何版本升级到任何版本.

但要回答你的上一个问题,是的,迁移有点严重.他们在另一个修订控制系统之上实施冗余修订控制系统.但是,这些修订控制系统都不是真正与数据库同步.

只是为了解释其他人所说的内容:迁移允许您在架构发展过程中保护数据.schema.rb只有在您的应用程序投入生产之后,维护单个文件的概念才具有吸引力.此后,您需要一种在架构更改时迁移现有用户数据的方法.

还有一些重要的数据相关问题需要考虑,迁移可以解决这些问题.

假设我的架构的旧版本有一个feet和inches列.出于效率目的,我想将其组合成一个inches列,以便更轻松地进行排序和搜索.

我的迁移可以将所有英尺和英寸数据组合到英寸列(英尺*12 +英寸),同时更新数据库(即在删除feet列之前)

显然,在迁移中,当您稍后将更改应用于生产数据库时,它会自动运行.