db迁移回滚的有用性
很多人都在谈论db迁移，特别是关于它的回滚可能性。
我怀疑它是否有用，因为db和model的模式与应用程序逻辑（MVC）紧密相关。
假设我已经完成了一些迁移的回滚。 什么？ 应用程序将无法运行，因为它的逻辑完全依赖于db。
db迁移的回滚function有哪些用例？
更新1
主要问题
当我需要更改代码时，为什么回滚会显示为function？
我不创建迁移，例如“add_another_field_to_table”。 相反，每个迁移文件都完整地描述了DB中的每个表。 当我需要更改数据库中的内容时，我只需更改迁移文件，但不要回滚 。
真的，如果我回滚迁移， 它不会像版本控制那样让我回到过去 。 我有很多工作，当计划更改并且回滚没有给我任何东西。
回滚的重点是您同时回滚代码和数据库。 方案是您在生产服务器上升级代码和数据库，然后您发现了一个错误，您真的需要返回。 因此，回滚代码并使用向下迁移来回滚数据库。
Up迁移有什么意义？
- 您创建表结构。
- 你编码它，它运作良好。
- 你把网站投入生产，每个人都很开心。
- 哦，等等，他们想要一个新function，包括在现有表中添加一列。
你怎么处理这个？ 您必须在开发表中添加一列，测试代码，更新实时站点而不要忘记同时更新实时数据库（如果您这样做会有大错误）并且还要记住以保留现有的实时数据。 如果没有类似rails的良好托管解决方案，数据库管理的这一方面可能会非常痛苦。
所以……
- 编写添加列的单行迁移
- 在开发副本上运行迁移，scehma.rb将更新
- 编码新function，如果需要检查数据库架构使用schema.rb NOT迁移文件。
现在你准备发布生产….
- 更新生产代码
- 在生产上运行迁移。 Rails会自动计算出需要应用的内容并为您完成！
当然，随着你添加一列，你自己做的并不是那么令人困惑。
但如果有3名程序员都添加了迁移呢？ 如果您有许多不同版本的实时网站怎么办？ 现场2或17次迁移是否落后？ 在保留实时数据的同时，我需要做些什么才能使数据库达到最新代码？ 你能看出这会如何迅速让人难以理解吗？
Rails迁移（实际上每个迁移系统都遵循相同的原则）旨在使更新DB结构变得非常容易。 值得正确使用。
我发现回滚只有在本地完成时才有用，即在你处理新代码时。 一旦迁移已经提交到您的版本控制系统中，如果您意识到存在错误，那么它实际上无法回滚迁移，因为其他开发人员会将迁移撤下并运行它，因此您需要告诉他们回滚 – 这太难管理，也让你看起来不称职:)
在这种情况下更好地进行另一次迁移以解决问题，然后每个人（包括您的生产服务器）都坚持使用pull＆migrate系统。
不是真的了解你的问题，但我试着解释一下回滚。 如果要通过相应的迁移撤消更改，则执行回滚操作。 这意味着将修改数据库，并且还将自动重新生成schema.rb。 当你这样做时，你可能也想删除引用代码。 例如，如果从模型中删除了某个字段，可能您不希望在代码中引用该属性。 如果您尝试访问，那么将为您提供未定义的属性exception。 而已。 例如，如果之前创建了一些模型10迁移，并且您想要更改某些字段，则回滚可能会变得有点麻烦。 最好创建一个新的迁移并在那里进行修改，而不是回滚到相应的迁移。
更新1
阅读您的更新，我认为你不使用迁移的主要优势，灵活性。 但是您的解决方案提供了更多数据库情况的概述。 如果你喜欢这样做，我建议按顺序执行以下步骤。
- 回滚到相应的迁移。（
rake db:migrate VERSION=XXX，我更喜欢rake db:rollback STEP = 2例如，回滚2次迁移，STEP可选） - 进行更改
- 迁移数据库以更新所有表，并获取当前迁移版本。（
rake db:migrate）
此function不会影响您的模型或其他内容，只需更改迁移文件，重新生成schema.rb并更改数据库结构，不做任何其他操作。 不能像版本控制系统那样进行代码回滚，并且没有意义去做那样的事情。 你必须注意不要使用删除的字段。 Rails具有数据库字段和模型属性之间的自动映射，例如，如果comment表中有user_id ，则可以将其称为模型中的属性comment_instance.user_id 。 希望这是有道理的。
考虑使用capistrano部署站点并为每个部署创建带时间戳的快照的方案。 使用文件夹和迁移的时间戳，您可以确定哪些版本的代码和架构齐头并进行回滚。
git存储库会为您提供类似的选项。
当然，真正的问题是，一旦站点的用户开始添加数据，那么也可能会被清除，除非您在回滚之前备份它并在以后艰苦地恢复它。
在处理迁移代码时和最终提交之前，我在本地使用rake db:migrate:redo进行迁移回滚。