我继承了一个使用实体框架的ASP-Net-Core MVC项目。该项目包含许多数据库迁移，而且它只在我的公司内部使用。所有运行该项目的环境都已将数据库迁移到最新版本。
我仍在学习实体框架，但据我所知，该项目使用迁移的方式是非正统的：其中一些包括用于数据填充的自定义SQL脚本，我认为这些脚本不属于迁移，它们与EF命令行工具集成不好，实际升级是在启动应用程序时通过调用迁移方法临时完成的。
考虑到所有环境都在运行最新的数据库版本，有什么理由保持这些迁移？对我来说，它看起来像是死代码。如果将来需要进行新的迁移，那么我可以采用更严格的方法。
在您的公司中，如果不是通过迁移，数据库模式是如何建立的？
假设我想提供一个新的数据库，例如，因为我们将运行该应用程序的第二个实例，但使用全新且不相关的数据。我需要做些什么才能使这个数据库的结构保持最新？
这里有几种可能性，我很好奇贵公司采取哪种方法。
一种方法是将迁移作为唯一的源。也就是说，您从一个空数据库开始，您添加的任何内容(或以后的更改(都被视为迁移。因此，要从头开始创建新数据库，只需创建一个新的(空的(数据库并重播迁移即可。
因此，您不能放弃旧的迁移。
其次，贵公司是否保留数据库备份？他们是否还有最近一次迁移之前的备份？
假设我们恢复了一个旧备份，当我们删除了迁移逻辑时，如何使它恢复正常工作？
这也是继续迁移的一个很好的理由。
总的来说，你的问题受到了相当普遍的"；事情只会变得更好"每个开发人员都会在某个时刻挣扎的态度。情况并非总是如此。
例如，您可以说，有错误修复的代码库比修复之前的相同代码库要好但是这不是在提交这些修复程序之前删除源代码管理历史记录的原因。
首先，这是一个记录的问题。其次，总有可能所做的改变最终会带来一些并不明显的问题。
在这种情况下，回滚的能力可能变得必要。此外，如果回滚的能力变得必要，这反过来也说明您需要您的迁移逻辑，既用于向下迁移(即回滚，但保留新数据(，也用于解决当前问题后将要执行的未来向上迁移。