我正在尝试在我的应用程序中找出合适的数据库开发过程。我已经尝试过使用后/预部署脚本(非常好的功能)、 Entity Framework 数据库优先方法(在源代码控制下为每个数据库更改使用单独的脚本)的 Visual Studio 数据库项目，现在我正在处理 Entity Framework 代码优先方法。我不得不说它提供的可能性给我留下了深刻的印象，但我正在努力弄清楚如何在开发过程中管理模型中的变化。假设我的公司有以下环境:
LOCALHOST - 对于每个开发人员，
TEST - 用于测试目的的带有 SQL Server 数据库的单机，
生产 - 客户端使用 SQL Server 数据库的单机
现在，每次我处理应用程序并且代码发生更改时，每次测试应用程序时都可以删除并重新创建数据库(对于 LOCALHOST 和 TEST 环境也是如此)。我已经创建了适当的数据库初始值设定项，用测试数据为数据库提供种子，我对它们非常满意。
但是，对于模型更改时的每个新构建，我希望以不会丢失整个数据的方式处理 PRODUCTION 数据库更改。因此，在 Visual Studio 2012 中有“SQL Schema Compare”工具，我只是想知道管理数据库中用于 PRODUCTION 开发的所有更改是否还不够？我可以将我的 {local} 数据库架构与 PRODUCTION 架构进行比较并简单地应用所有更改吗？
现在，我想问一下 Code First Migrations 在这里有什么意义？为什么我要通过它管理数据库中的所有更改？我能找到的唯一原因是允许执行各种“插入”和“更新”命令。但是我认为如果数据库设计正确，则不需要执行这些命令。 (这是另一个讨论的主题，所以我不想详细介绍)。无论如何，我想问 - Code First 迁移相对于 Code First + Schema Compare 模式的真正优势是什么？
最佳答案
它简化了部署。如果您没有在代码中管理迁移，则必须在生产环境中手动运行适当的增量脚本。使用 EF 迁移，您可以将应用程序配置为在启动时自动将数据库迁移到最新版本。
通常，在 EF 迁移之前，如果您想自动执行此操作，您要么必须在自定义安装例程期间运行适当的增量脚本，要么将一些基础结构写入您的应用程序中，以在代码中运行增量脚本。这需要知道当前的数据库版本，以便它知道要运行哪些脚本，您通常会在 DbVersion 表或类似的东西中拥有这些脚本。借助 EF 迁移，此管道已为您准备就绪。
使用迁移意味着模型和数据库更改的对齐是自动化的，因此更易于管理。
关于database - 代码优先迁移 - 真的有必要吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/12130609/