往年的EF迁移

Question

最近四年来我一直在一个项目中工作。目前，我们已经进行了2510次迁移，并且随着系统变得更加复杂并添加了新功能，预计还会继续增加。

进行这种数量的迁移是一种好/不好的做法吗？

我们正在讨论删除所有迁移并创建一个代表整个数据库的新迁移的选项，但是我们不知道这是一个好习惯。有人有做这种东西的经验吗？

Answer 1

如果您可以从头进行重建，那么迁移过多就没有什么不好。在可以正常工作的生产环境中，迁移实际上仅是启动和运行开发机器或回滚不良发行版的一种方法。

但是，我个人喜欢不时地重置迁移。我们有同样的问题，数千次迁移，并且由于提交时的人为错误以及名称空间更改（在此处插入原因），不太可能在较长的时间内重建。

事实上，无论是生产还是生产，它都永远不会被重建，它仅适用于开发测试机。

尽管有一些非常不利的方面的风险，如果您的UP中有自定义代码和脚本来执行各种操作（您可能会这样做），则必须小心并重新添加它们，并备份所有内容！

_{免责声明 ，除非他们确切知道自己在做什么，否则我不会提倡任何人这样做。进行大量迁移是可以的，并且在任何正常情况下都不会造成问题，但是，破坏生产数据库可能会花费很多。}

---

进一步阅读

如果您想解决这个问题

• Resetting Entity Framework Migrations to a clean Slate
• Reset Entity-Framework Migrations

Answer 2

我认为not_collapsing_migrations发生collapsing_migrations的风险。

C-崩溃中的迁移

风险：

• C_R1-结果数据库不是应该的，因为：
  • 创建摘要迁移时，单个迁移中的自定义更改会丢失
  • 其他原因
• C_R2-部署风险：部署不简单（包括修改migration_history表）

好处：

• C_B1-重新启动db的代码启动速度更快（快多少？）
• C_B2-清洁解决方案
• C_B3-当前迁移包含新数据库版本中不推荐使用的操作
• C_B4-（我不建议这样做，请参见下文）如果最初使用较新版本的EF完成，则新版本的EF可能会创建更好的SQL，甚至可能修复错误或突出显示问题。

NC-不崩溃的迁移

• NC_R3-迁移达到极限-在PROD之前应检测到影响极小（不太可能）

---

反正...让我们这样做

我不建议这样做，但是如果您决定取消迁移，则可以使用以下两种方法来降低风险C_R1（结果db！=当前数据库，因为某些自定义代码“丢失了翻译”）。

A。使用外部工具创建代表数据库的初始脚本，并使用生成的sql作为首次新迁移的基础（与仅运行Add-Migration和使用EF附带的代码相反）。

B。使初始迁移包含所有迁移中的代码（与仅运行Add-Migration和使用EF附带的代码相反）。