我继承了一个使用实体框架的 ASP Net Core MVC 项目。该项目包含多个数据库迁移，仅在我公司内部使用。运行该项目的所有环境都已将数据库迁移到最新版本。
我仍在学习实体框架，但据我了解，该项目使用迁移的方式是非正统的：其中一些包含用于数据填充的自定义 SQL 脚本，我认为这些脚本不属于迁移，它们没有很好地集成使用 EF 命令行工具，实际升级是通过在启动应用程序时调用迁移方法临时完成的。
考虑到所有环境都在运行最新的数据库版本，有什么理由保留这些迁移？对我来说，它看起来像死代码，有效地。如果将来需要新的迁移，那么我可以采用更加按部就班的方法。
【问题讨论】：
标签： c# entity-framework asp.net-core-mvc entity-framework-migrations
在您的公司中，如果不是通过迁移，数据库架构是如何建立的？
假设我想提供一个新的数据库，例如因为我们要运行这个应用程序的第二个实例——但是使用全新的和不相关的数据。我需要做什么才能使这个数据库在结构上保持最新？
这里有几种可能性，我很好奇贵公司采取了哪种方法。
一种方法是使用您的迁移作为唯一来源。 IE。您从一个空数据库开始，您添加（或稍后更改）的任何内容都被视为迁移。因此，要从头开始创建新数据库，您只需创建一个新（空）数据库并重放迁移。
因此，您不能只是丢弃旧的迁移。
其次，贵公司是否保留数据库备份？他们是否还有上次迁移之前的备份？
假设我们恢复一个旧的备份，当我们删除了迁移逻辑后，我们如何让它恢复工作状态？
这也是保持迁移的一个很好的理由。
总体而言，您的问题受到了每个开发人员在某些时候都在努力应对的相当普遍的“事情只会变得更好”的态度。情况并非总是如此。
例如，您会说带有错误修复的代码库比修复之前的相同代码库要好。 但是这不是在提交这些修复程序之前删除您的源代码控制历史记录的理由。
首先，这是一个记录保存的问题。其次，所做的更改总是有可能最终带来一些不明显的问题。
在这种情况下，可能需要回滚功能。此外，如果回滚的能力变得必要，那么这反过来也表明您需要您的迁移逻辑，既用于向下迁移（即回滚但同时保留新数据），也用于您将要执行的未来向上迁移一旦当前的问题得到解决。
【讨论】：