对现有 Entity Framework Code First 数据库进行重大更改的最佳方法是什么？答案

【问题标题】：What is the best approach for making major changes to an existing Entity Framework Code First database?对现有 Entity Framework Code First 数据库进行重大更改的最佳方法是什么？
【发布时间】：2013-11-01 05:16:16
【问题描述】：

我已经使用 Entity Framework Code First 创建了一个 MVC 项目。该项目有一个相当大的数据库，并且正在生产中。现在，我正在添加一大组新功能，这些功能将使数据库的大小（表数）几乎翻倍。在我开发它时，我希望对 POCO 对象和 Fluent 模型构建逻辑进行大量调整。但是，我不希望有 100 次“迁移”，因为我做了一些小改动。

如果我先使用数据库，我会更改数据库并迭代地重新创建模型。完成后，我可以将最终架构与之前的架构进行比较并创建更改脚本。

我倾向于创建一个新的临时 DbContext 并为那里的新表开发我的 Code First 模型，并在迭代时从头开始重新创建一个新数据库。然后，当我拥有满意的模型时，将其移至主 DbContext 并创建一个大迁移。但这似乎很痛苦。它还存在一个问题，即新对象和现有对象之间存在一些需要放置到位的关系。

所以，我的具体问题是如何对 Code First 数据库进行许多小的更改：

无需重新创建现有数据库
并且没有为我要测试的每个更改创建（永久）迁移

【问题讨论】：

标签： entity-framework ef-code-first

【解决方案1】：

您说您使用 Code First 创建了项目，所以我假设您不需要 reverse engineer 数据库。

为避免重新创建现有数据库，请使用 MigrateDatabaseToLatestVersion database initializer

为避免为每次更改创建永久迁移，您可以回滚每个次要更改，然后强制迁移重新运行。

要回滚：Update-Database -TargetMigration 0

强制迁移重新运行：Add-Migration "OneMigrationToRuleThemAll" -Force

另一方面....

学会停止为小事出汗需要决定什么要做的事情和要忽略的事情

（理查德·卡尔森）

这些tips for Entity Framework migrations 值得一读

【讨论】：

谢谢科林。文章中的引述“迁移非常强大。当他们工作时，它很棒，但是当出现问题时试图确定发生了什么可能会非常令人沮丧。”钱是对的。关于“停止出汗”这句话，我不确定我是否明白你的意思。我的意思是我喜欢并完全同意这句话，但我只是想确保在弄乱数据库之前采取明智的方法。我是不是想太多了？
在达到 100 之前，我还有大约 50 次迁移要做。但我相信我最终会到达那里。如果它打扰您，请尽可能关闭该文件夹。
好吧，我已经学会了停止对迁移的恐惧并拥抱它们。练习迁移，带上新的迁移并删除它们。不要担心你创造了多少……谢谢科林。
:-) 不过我确实把提琴手扔回去了