为什么使用数据库迁移而不是版本控制模式
迁移无疑比仅仅启动 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 方法时，你将会失去保真度。
无论如何，我的问题是，即使你想不出更好的方法，迁移不是很恶心吗？
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.
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?
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?
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!
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
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
因为数据库本身与版本控制不同步。
例如，您可以使用源树的头部。 但是您连接到的数据库被定义为某个过去的版本，而不是您已签出的版本。 迁移允许您以增量方式将数据库架构从任何版本升级或降级到任何版本。
但要回答你的最后一个问题，是的，迁移有点恶心。 他们在另一个版本控制系统之上实现了一个冗余版本控制系统。 然而，这些版本控制系统都没有真正与数据库同步。
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.
只是为了解释其他人所说的：迁移允许您随着架构的发展来保护数据。 仅在您的应用投入生产之前，维护单个
schema.rb文件的概念才有吸引力。 此后，您将需要一种在架构发生更改时迁移现有用户数据的方法。Just to paraphrase what others have said: migrations allow you to protect the data as your schema evolves. The notion of maintaining a single
schema.rbfile is attractive only until your app goes into production. Thereafter, you'll need a way to migrate your existing users' data as your schema changes.还有一些与数据相关的问题需要考虑，迁移可以解决这些问题。
假设我的架构的旧版本有一个
feet和inches列。 出于效率目的，我想将其合并到一个“英寸”列中，以便更轻松地排序和搜索。我的迁移可以在更新数据库时（即在删除
feet列之前）将所有英尺和英寸数据合并到英寸列（英尺 * 12 + 英寸）中，显然这是在迁移中当您稍后将更改应用到生产数据库时，它会自动工作。
There are also data-related issues that are important to consider, which migrations solve.
Say an old version of my schema has a
feetandinchescolumn. For efficiency purposes, I want to combine that into just aninchescolumn to make sorting and searching easier.My migration can combine all of the feet and inches data into the inches column (feet * 12 + inches) while it's updating the database (i.e. just before it removes the
feetcolumn)Obviously this being in a migration makes it automatically work when you later apply the changes to your production database.
就目前而言，它们很烦人且不充分，但很可能是我们目前可用的最佳选择。 很多聪明人花了相当多的时间来解决这个问题，到目前为止，这大概是他们能想出的最好的办法了。 经过大约 20 年的大部分手动编码数据库版本更新后，当我发现 ActiveRecord 时，我很快意识到迁移是一项重大改进。
正如你所说，版本控制是一个已解决的问题。 在某种程度上，我同意：特别是对于文本文件来说，它已经得到了很好的解决，对于其他文件类型来说，情况就不太好，对于数据库等资源来说，则根本不是很好。
如果将迁移视为数据库的版本控制增量，它们会是什么样子？ 它们是您必须应用以将模式从一个版本转换为另一个版本的增量的总和。 我不知道即使是 git，尽管其功能非常强大，也可以获取两个模式文件并生成必要的 DDL 来执行此操作。
至于在模型中声明表内容，我相信这就是 DataMapper 所做的（没有个人经验）。 我认为那里可能也有一些 DDL 推理功能。
“即使你想不出更好的办法，移民不是很恶心吗？”
是的。 但它们比我们拥有的任何其他东西都没有那么恶心。 当您完成非严重替代方案时，请告诉我们。
As it stands, they're annoying and inadequate but quite possibly the best option we have available to us at present. Quite a few smart people have spent quite a lot of time working on the problem and this, so far, is about the best they've been able to come up with. After about 20 years of mostly hand-coding database version updates, I came very rapidly to appreciate migrations as a major improvement when I found ActiveRecord.
As you say, version control is a solved problem. Up to a point I'd agree: it's very solved for text files in particular, less so for other file types and not really very much at all for resources such as databases.
How do migrations look if you view them as version control deltas for databases? They're the sum of the deltas you have to apply to get a schema from one version to another. I'm not aware that even git, for all its super-powerfulness, can take two schema files and generate the necessary DDL to do that.
As far as declaring table content in the model, I believe that's what DataMapper does (no personal experience). I think there may be some DDL inference capabilities there as well.
"even if you can't think of a better way, aren't migrations kind of gross?"
Yes. But they're less gross than anything else we have. Do please let us know when you've completed the non-gross alternative.
我想考虑到“即使你想不出更好的方法”，那么是的，从长远来看，迁移是有点恶心的。 Ruby、Rails、ORM、SQL、Web 应用程序也是如此……
迁移具有它们存在的（并非微不足道的）优势。 粗俗但存在往往会胜过愉快但不存在。 我确信可能有令人愉快且不存在的方法来迁移数据，但我不确定这意味着什么。 :-)
I suppose given "even if you can't think of a better way", then yes, in the grand scheme of things, migrations are kind of gross. So are Ruby, Rails, ORMs, SQL, web apps, ...
Migrations have the (not insignificant) advantage that they exist. Gross-but-exists tends to win out over Pleasant-but-nonexistent. I'm sure there probably are pleasant and nonexistent ways to migrate your data, but I'm not sure what that means. :-)
好吧，我在这里大胆猜测一下，你可能正在独自工作。 在小组开发项目中，每个人对开发人员编写的代码所需的数据库更改负责的能力要重要得多。
另一种选择是，较大的程序员群体（例如，我工作的地方有 10-15 个 Java 开发人员）最终会依赖几个专门的全职数据库管理员来完成这项工作以及其他维护、优化等职责。
OK, I'm going to take a wild guess here and say that you're probably working all by yourself. In a group development project the power of each individual to take responsibility for just his/her changes to the database required for the code that developer is writing is much much more important.
The alternative is that larger groups of programmers (e.g. 10-15 Java developers where I work) end up relying on a couple of dedicated full time database administrators to do that along with their other maintenance, optimization, etc. duties.