许多人在谈论数据库迁移，特别是关于其回滚的可能性。数据库迁移回滚的有用性
我怀疑它是否有用，因为db和model的模式与应用程序逻辑（MVC）紧密相连。
假设我已经完成了一些迁移的回滚。什么？该应用程序将无法工作，因为它的逻辑完全依赖于数据库。
数据库迁移的回滚能力的用例是什么？
更新1
的主要问题
为什么回滚是作为一个功能，当我需要改变的代码？
我不创建迁移，像 “add_another_field_to_table”。相反，每个迁移文件都完整描述了数据库中的每个表。当我需要在我的数据库中更改某些内容时，我只是更改迁移文件，但不会将其回滚到。
真的，如果我回滚迁移，它不会使我回到时间，就像版本控制一样。我有很多工作，当计划进行更改时，回滚没有给我提供任何帮助。
回滚点在于您同时回滚代码和数据库。该场景是您在生产服务器上升级您的代码和数据库，然后发现错误并确实需要返回。因此，回滚您的代码并使用您的向下迁移来回滚您的数据库。
真的不明白你的问题，但我试着解释一下回滚。 如果您想通过相应的迁移撤消更改，则执行回滚。这意味着数据库将被修改，并且您的schema.rb将自动重新生成。当你这样做时你可能也想删除引用代码。例如，如果您从模型中删除了一个字段，可能您不希望在您的代码中引用该属性。如果你尝试访问，那么会给你未定义的属性异常。而已。 例如，如果您之前创建了一些模型10迁移，并且您想要更改某些字段，可能会变得有点麻烦。最好创建一个新的迁移并在那里修改，而不是回滚到相应的迁移。
更新1
阅读您的更新，我想哟不要用迁移的主要优势，灵活性。 但是，您的解决方案提供了有关数据库情况的更多概述。如果你喜欢这样做，我建议按顺序进行以下步骤。
rake db:migrate VERSION=XXX，我喜欢例如更好rake db:rollback STEP = 2，回滚2迁移，STEP可选）rake db:migrate）此功能不会影响您的模型或其他内容，只需更改迁移文件，重新生成schema.rb并更改数据库结构，而不是其他任何操作。不能像版本控制系统那样执行代码回滚，并且没有意义做类似的事情。你必须小心不要使用删除的字段。例如，如果您的comment表中有user_id，则可以将其称为模型comment_instance.user_id中的一个属性，Rails在数据库字段和模型属性之间具有自动映射。 希望这是有道理的。
我认为一个理解，什么是迁移是关于。他们将数据保存在生产服务器的数据库中。我可以在不触及其他表格中的数据的情况下进行小修改。我对吗 ？ – AntonAL 2010-09-27 09:23:42
那么，如果你像你一样使用你的迁移，你也必须在你的生产模式中执行这3个步骤（步骤1,3也可以），但这有点不好意思，这就是为什么你在改变时使用新的迁移数据库，在更新生产模式中的更改时也可以使这些黑客无效。无论如何，您不需要像组织那样使用迁移，您的表的字段可以在不同的迁移中，因为schema.rb不会丢失。如果你需要桌子的结构，你可以从那里得到。 – dombesz 2010-09-27 09:40:23
Up迁移有什么意义？
你是如何处理这个问题的？您必须在开发表中添加一列，测试代码，更新现场而不忘记同时更新现场数据库（如果您这样做，将会出现大错误）并且还要保留现有的实时数据。如果没有像rails这样的好管理解决方案，数据库管理的这一方面可能是一个真正的痛苦。
所以......
现在你准备好发布生产....
当然，在添加一列的时候，并不是你自己搞混乱。
但是如果有3位程序员全部添加了迁移呢？如果你有很多活网站，所有版本都不一样？那个活网站2或17迁移落后了吗？我需要做些什么才能使数据库保持最新的代码，同时保留实时数据？你能否看到这很快就会让人感到困惑？
Rails迁移（实际上每个迁移系统的工作原理都相同）旨在使更新DB结构变得非常简单。值得正确使用。
考虑使用capistrano来部署站点并为每个部署创建时间戳快照的场景。通过使用文件夹和迁移的时间戳，您可以确定代码和模式的哪些版本齐头并进行回滚。
一个git仓库会给你类似的选项。
当然，真正的问题是，一旦网站的用户开始添加数据，那么这些数据可能会被清除，除非您在回滚之前将其备份，并在以后的日子里精心恢复。
我发现回滚只有在本地完成时才有用，也就是说，当您正在处理新的代码时。一旦迁移到您的版本控制系统，如果您意识到存在一个错误，那么它并没有真正的回滚迁移，因为其他开发人员已经将迁移拉下来并运行，所以您需要告诉他们回滚 - 这太难以管理，也让你看起来无能为力:)
在这种情况下更好的做只是做另一个迁移来解决问题，然后每个人（包括你的生产服务器）只是坚持随着&迁移系统。
我同意这似乎是最常见的用例。与OP一样，我也看不到主要数据库回滚过程的真正好处。大多数正常的模式更新都是非破坏性的设计，因为消费的生产软件在应用更新时不得中断。因此，即使您必须回滚生产代码，通常也可以保留更新的模式，如有必要，只需应用一些额外的迁移，而不是回滚并重新应用原始迁移的修改版本。 – 2016-04-09 21:49:52
在处理迁移代码和最终提交之前，我使用本地迁移回滚rake db:migrate:redo。
“我没有创建迁移，比如”add_another_field_to_table“，而是每个迁移文件都完全描述了数据库中的每个表，当我需要更改数据库中的某些内容时，我只是更改迁移文件”你能解释一下这更进一步，因为这听起来很奇怪。当您需要添加列时，您不需要进行新的迁移，而是编辑旧的迁移？这听起来像你没有正确地使用迁移... – James 2010-09-27 08:56:42
是的，我也认为。我没有注意到部分迁移的好处。他们只是模糊了目前迁移过程中的大局。我知道，那个schema.rb文件就是为了这个。但是，部分迁移只会减慢我的工作速度，因为当我需要查看数据库中的某个表时，我需要跳过几个“add_column_to_table”迁移文件。但是，他们的真正好处是什么？我还不知道答案... – AntonAL 2010-09-27 09:05:12