为什么使用数据库迁移而不是版本控制模式 [英] Why use database migrations instead of a version controlled schema

问题描述

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

Migrations are undoubtedly better than just firing up phpMyAdmin and changing the schema willy-nilly (as I did during my php days), but after using them for awhile, I think they're fatally flawed.

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

Version control is a solved problem. The main function of migrations is to keep a history of changes to your database. But storing a different file for each change is a clumsy way to track them. You don't create a new version of post.rb (or a file representing the delta) when you want to add a new virtual attribute -- why should you create a new migration when you want to add a new non-virtual attribute?

换句话说，就像你将 post.rb 签入版本控制一样，为什么不将 schema.rb 签入版本控制并直接对文件进行更改?

Put another way, just as you check post.rb into version control, why not check schema.rb into version control and make the changes to the file directly?

这在功能上与为每个 delta 保留一个文件相同，但使用起来要容易得多.我的心智模型是我希望表 X 有这样那样的列(或者说真的，我希望模型 X 有这样那样的属性)"——你为什么要从现有的模式中推断出如何到达那里?只需打开 schema.rb 并为表 X 提供正确的列！

This is functionally the same as keeping a file for each delta, but it's much easier to work with. My mental model is "I want table X to have such and such columns (or really, I want model X to have such and such properties)" -- why should you have to infer from this how to get there from the existing schema; just open up schema.rb and give table X the right columns!

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

But even the idea that classes wrap tables is an implementation detail! Why can't I just open up post.rb and say:

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

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

If you went with a model like this, you'd have to make a decision about what to do with existing data. But even then, migrations are overkill -- when you migrate data, you're going to lose fidelity when you use a migration's down method.

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

Anyway, my question is, even if you can't think of a better way, aren't migrations kind of gross?

推荐答案

为什么不将 schema.rb 检入版本控制并直接对文件进行更改?

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

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

Because the database itself is not in sync with version control.

例如，您可以使用源代码树的头部.但是您正在连接到一个被定义为某个过去版本的数据库，而不是您已签出的版本.迁移允许您以增量方式将数据库架构从任何版本升级或降级到任何版本.

For instance, you could be using the head of the source tree. But you're connecting to a database that was defined as some past version, not the version you have checked out. The migrations allow you to upgrade or downgrade the database schema from any version and to any version, incrementally.

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

But to answer your last question, yes, migrations are kind of gross. They implement a redundant revision control system on top of another revision control system. However, neither of these revision control systems is really in sync with the database.

这篇关于为什么使用数据库迁移而不是版本控制模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！