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