数据库迁移“向下”的意义何在？
与所有数据库一样，我们的源代码使用源代码控制进行版本控制。数据库的升级使用了Red Gate的比较工具生成的一系列SQL脚本，这与最近兴起的众多数据库迁移框架中的“向上”迁移本质上是一样的。
但是这些框架中的“向下”迁移有什么意义呢？通常，“向上”迁移的代码非常复杂（随着功能的发展，数据迁移通常会变得复杂），并且我很难理解必须为“向下”迁移反向编写所有代码的目的。这当然是我从未觉得有必要的事情。我在这里错过了什么吗...？
As all databases should be, the source for ours is versioned using source control. The database is upgraded using a series of SQL scripts generated by Red Gate's comparison tool, which is essentially the same as an 'up' migration in the numerous database migration frameworks that seem to have sprung up recently.
But what's the point in the 'down' migrations in these frameworks? Often the code for the 'up' migration is extremely complex (typically complex data migration as features evolve) and I struggle to see the purpose of having to write it all in reverse for the 'down' one. It's certainly something I've never felt the need for. Am I missing something here...?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这里的相关问题似乎是：
我可以想到几个原因：
数据库非常大 - 比如说几百 GB - 并且您的公司无法承受完整恢复所涉及的停机时间和/或管理开销。
引入了一个错误，直到投入生产一两周才发现。如果您以前从未经历过这种情况，那么您很幸运。一旦您在新数据库中获得了一周的事务量，您就可以忘记从备份中恢复。
直到发布后几个月才发现该错误。换句话说，您甚至不再拥有备份，并且您正式处于损坏控制/灾难恢复模式。我从未经历过这种事，但我听过一些故事。这是一个可怕的想法——如何消除所造成的所有损害？在这种情况下，您的降级可能并不完美，但它可能仍然比替代方案更好。
相比之下，也许数据库更改是微不足道的 - 此处添加几行，那里添加一些触发器。在这种情况下，脚本回滚将比恢复花费更多的时间。某些需要数小时才能升级的内容（例如创建新索引或添加新列）可能只需要几秒钟即可降级（删除）。
您正在部署到客户站点。其中一些可能根本没有备份（是的，这很可悲，但你对此无能为力）。如果其中一个需要回滚，这是您唯一的选择。
可能还有其他原因需要降级脚本 - 这只是我的想法。
It seems that the pertinent question here is:
I can think of several reasons:
The database is very large - say a few hundred GB - and your company cannot afford the downtime and/or administrative overhead that would be involved in a full restore.
A bug was introduced that was not discovered until a week or two into production. If you've never experienced this before, you're lucky. Once you've got a week's worth of transactions in the new database, you can forget about just restoring from backup.
The bug was not discovered until months into the release. In other words, you don't even have the backup anymore, and you're officially in damage control/disaster recovery mode. I've never experienced this, but I've heard stories. It's a scary thought - how do you undo all the damage that was done? In this case your downgrade might not be perfect, but it might still be better than the alternative.
By contrast, perhaps the database changes were trivial - adding a few rows here, a few triggers there. In this case, a scripted rollback is going to take much less time than a restore. It's possible that some things that took hours to upgrade - such as creation of new indexes or addition of new columns - may only take seconds to downgrade (drop).
You're deploying to customer sites. Some of them may not have backups at all (yeah, it's pathetic, but there's nothing you can do about it). If one of them needs a rollback, this is your only option.
There may be other reasons to have downgrade scripts - this is just off the top of my head.
顾客：“我们不喜欢新版本，想回到旧版本。”
Customer: "We don't like the new version and want to go back to the old version."
如果您升级，并且随后将要保留的数据添加到数据库中，则回滚脚本（只要它是这样设计的）应该可以实现此目的，而如果您只是恢复备份，您将丢失它。
但是您可以通过恢复备份并使用 SQL 数据比较来复制其他数据来解决上述问题。
If you upgrade, and subsequently data is added to your database that you want to preserve, a rollback script (as long as it is designed as such) should achieve this, whereas if you simply restore a backup you'll lose it.
But you could get round the above by restoring a backup and using SQL Data Compare to copy the additional data across.