短版本：
down迁移有什么问题？在什么情况下，您需要使用一个？
长版本：
许多支持数据库模式版本的框架（包括但不限于Rails的"迁移"）允许开发人员指定如何逆转数据升级（up操作）（也称为down），甚至通过分析代码自动生成降级操作（如Rails的change方法）。
事实上，在我遇到的所有Rails迁移代码中，这样做似乎非常常见，这让我怀疑这是否被认为是一种最佳实践。
就我个人而言，我从来没有需要降级数据库模式，而且我无法想象在开发或生产中有一个合理的场景。我的经验似乎与down迁移的流行率不一致，所以我想我错过了一些东西。。。
down最常用的场景是什么？
假设您已经将一个新版本推送到生产环境中并运行迁移，但一段时间后您发现了一个无法立即解决的错误。由于您需要保持生产服务器的运行，因此可以恢复到以前的提交。然而，这不会恢复对数据库所做的更改，这将导致错误。因此，您需要一种方法来回滚对数据库所做的更改，然后恢复到旧版本。这种情况可能不会经常出现，但重要的是要有一个机制来应对这种情况。
在开发过程中，您可能会运行一些迁移，然后决定要更改、添加或删除某些内容。有一种方法可以撤消它们意味着你不需要为每一个小的更改创建一个新的迁移。
实践的两个原因：
- 开发环境中的代码重构-我们可以恢复数据库架构，重构模型&迁移，然后向上迁移再次
- 将"柠檬"发送到后汇总以前的应用程序版本生产
缺少"向下"迁移意味着，我们根本没有迁移，我们回到了90年代初，从备份中恢复数据库，或者痛苦地修改表，认为一切都应该顺利。
所以基本上，当你创建像这样的迁移时，Rails可以检测到反向操作
add_column => remove_column
create_table => drop_table
但是，对于某些不能真正使用更改来降级数据库模式的迁移，例如，如果您想更改十进制列的精度，那么就不可能猜测回滚时的原始精度？因此，在这种情况下，您需要定义down方法。