将所有环境迁移到最新版本后，是不是有理由保留 EF 迁移代码？

Posted 2023-02-16

【中文标题】将所有环境迁移到最新版本后，是不是有理由保留 EF 迁移代码？

【英文标题】：Are there reasons to keep EF migration code around once all environments have been migrated to the latest version?将所有环境迁移到最新版本后，是否有理由保留 EF 迁移代码？

【发布时间】：2021-04-16 11:29:30

【问题描述】：

我继承了一个使用实体框架的 ASP Net Core MVC 项目。该项目包含多个数据库迁移，仅在我公司内部使用。运行该项目的所有环境都已将数据库迁移到最新版本。

我仍在学习实体框架，但据我了解，该项目使用迁移的方式是非正统的：其中一些包含用于数据填充的自定义 SQL 脚本，我认为这些脚本不属于迁移，它们没有很好地集成使用 EF 命令行工具，实际升级是通过在启动应用程序时调用迁移方法临时完成的。

考虑到所有环境都在运行最新的数据库版本，有什么理由保留这些迁移？对我来说，它看起来像死代码，有效地。如果将来需要新的迁移，那么我可以采用更加按部就班的方法。

【参考方案1】：

在您的公司中，如果不是通过迁移，数据库架构是如何建立的？

假设我想提供一个新的数据库，例如因为我们要运行这个应用程序的第二个实例——但是使用全新的和不相关的数据。我需要做什么才能使这个数据库在结构上保持最新？

这里有几种可能性，我很好奇贵公司采取了哪种方法。

一种方法是使用您的迁移作为唯一来源。 IE。您从一个空数据库开始，您添加（或稍后更改）的任何内容都被视为迁移。因此，要从头开始创建新数据库，您只需创建一个新（空）数据库并重放迁移。

因此，您不能只是丢弃旧的迁移。

---

其次，贵公司是否保留数据库备份？他们是否还有上次迁移之前的备份？

假设我们恢复一个旧的备份，当我们删除了迁移逻辑后，我们如何让它恢复工作状态？

这也是保持迁移的一个很好的理由。

---

总体而言，您的问题受到了每个开发人员在某些时候都在努力应对的相当普遍的“事情只会变得更好”的态度。情况并非总是如此。

例如，您会说带有错误修复的代码库比修复之前的相同代码库要好。 但是这不是在提交这些修复程序之前删除您的源代码控制历史记录的理由。

首先，这是一个记录保存的问题。其次，所做的更改总是有可能最终带来一些不明显的问题。

在这种情况下，可能需要回滚功能。此外，如果回滚的能力变得必要，那么这反过来也表明您需要您的迁移逻辑，既用于向下迁移（即回滚但同时保留新数据），也用于您将要执行的未来向上迁移一旦当前的问题得到解决。

【讨论】：

关于第一个问题，我的理解是，对于从头开始的部署，EF 将根据当前（即最新）数据模型生成架构，即实体、属性、关系等。所以不需要迁移。

我们确实保留了备份，而且您在支持从迁移前备份恢复方面确实提出了很好的论据。这通常是保留迁移的原因，但是我认为我们不会保留上次迁移之前的备份，在这种情况下问题不适用。我非常清楚，在我们的职业中，使用代码并不总是会变得更好。对我来说真正的问题是“如果没有可以运行的场景，我还需要这段代码吗？”。当然，风险是我没有考虑一些有意义的场景:)

@elnigno：这是一种方法，我怀疑人们使用 EF 的最常见方法，但这不是唯一的方法。我从事过 EF 只生成迁移脚本但没有执行它的项目。 SQL 已被捕获，并将在选择的时间和地点手动部署（意味着不是由 EF，不一定由人工部署）。