为什么要使用数据库迁移而不是版本控制的架构 [英] 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?

这在功能上与为每个增量保留文件相同，但是使用起来要容易得多.我的思维模型是我希望表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屋！