我正在尝试在我的应用程序中找到合适的数据库开发过程。我已经尝试过使用Post / Pre部署脚本的Visual Studio数据库项目（非常好的功能），实体框架数据库第一种方法（在源代码管理下为每个数据库更改单独的脚本），现在我正在处理Entity Framework Code First做法。我不得不说，我对它给出的可能性印象深刻，但我正在试图弄清楚如何在开发过程中管理模型的变化。假设我公司有以下环境：
LOCALHOST - 对于每个单独的开发者， TEST - 带有SQL Server数据库的单机用于测试目的， PRODUCTION - 客户使用SQL Server数据库的单机
现在，每当我处理应用程序并且代码发生变化时，每次我测试应用程序时都可以删除并重新创建数据库（因此对于LOCALHOST和TEST环境）。我已经创建了适当的数据库初始化程序，用测试数据对数据库进行种子处理，我对它们非常满意。
然而，对于模型更改时的每个新构建，我想以这样一种方式处理PRODUCTION数据库更改，这样我就不会丢失整个数据。因此，在Visual Studio 2012中有“SQL模式比较”工具，我只是想知道是否还不足以管理数据库中的所有更改以进行PRODUCTION开发？我可以将我的{local}数据库架构与PRODUCTION架构进行比较，并简单地应用所有更改吗？
现在，我想问一下Code First Migrations的重点是什么？为什么要通过它管理数据库中的所有更改？我能找到的唯一原因是允许执行所有类型的“INSERT”和“UPDATE”命令。但是我认为如果数据库设计正确，就不应该执行这些命令。 （这是另一个讨论的主题，所以我不想详细介绍）。无论如何，我想问一下 - Code First Migrations相对于Code First + Schema Compare模式的真正优势是什么？
答案 0 :(得分：3)
它简化了部署。如果您未在代码中管理迁移，则必须在生产环境中手动运行相应的增量脚本。通过EF迁移，您可以将应用程序配置为在启动时自动将数据库迁移到最新版本。
通常，在EF迁移之前，如果要自动执行此操作，则必须在自定义安装例程期间运行相应的增量脚本，或者在应用程序中编写一些基础结构，以便在代码中运行增量脚本。这需要知道当前的数据库版本，以便它知道要运行哪些脚本，这些脚本通常在DbVersion表或类似的东西中。通过EF迁移，这个管道已经适合您。
使用迁移意味着模型和数据库更改的对齐是自动化的，因此更易于管理。