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

Question

迁移无疑比只是启动 phpMyAdmin 并随意更改架构(就像我在 php 时代所做的那样)要好，但是在使用它们一段时间后，我认为它们存在致命的缺陷。

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

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

这在功能上与为每个增量保留一个文件相同，但使用起来要容易得多。我的心智模型是“我希望表 X 具有这样那样的列(或者实际上，我希望模型 X 具有这样那样的属性)”——为什么您必须从中推断出如何从现有模式到达那里；刚打开schema.rb并为表 X 提供正确的列!

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

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

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

无论如何，我的问题是，即使你想不出更好的方法，迁移是不是有点恶心？

Answer 1

why not check schema.rb into version control and make the changes to the file directly?

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

例如，您可以使用源树的头部。但是您要连接到定义为某个过去版本的数据库，而不是您已 check out 的版本。迁移允许您以增量方式将数据库架构从任何版本升级或降级到任何版本。

但要回答你的最后一个问题，是的，迁移有点恶心。他们在另一个修订控制系统之上实现冗余修订控制系统。然而，这些版本控制系统都没有真正与数据库同步。