代码优先迁移——真的有必要吗？答案

【问题标题】：Code first migrations - is it really necessary?代码优先迁移——真的有必要吗？
【发布时间】：2012-08-21 06:28:34
【问题描述】：

我正在尝试在我的应用程序中找出合适的数据库开发过程。我已经尝试使用后/预部署脚本（非常好的功能）、实体框架数据库优先方法（在源代码控制下为每个数据库更改使用单独的脚本）的 Visual Studio 数据库项目，现在我正在处理实体框架代码优先方法。我不得不说，它所提供的可能性给我留下了深刻的印象，但我正试图弄清楚如何在开发过程中管理模型中的变化。假设我公司有以下环境：

LOCALHOST - 对于每个开发人员， TEST - 带有用于测试目的的 SQL Server 数据库的单机， PRODUCTION - 带有客户端使用的 SQL Server 数据库的单机

现在，每当我在处理应用程序并且代码发生更改时，我可以在每次测试应用程序时删除并重新创建数据库（对于 LOCALHOST 和 TEST 环境也是如此）。我创建了适当的数据库初始化程序，用测试数据为数据库播种，我对它们非常满意。

但是，当模型更改时，每次新构建时，我都希望以不会丢失整个数据的方式处理 PRODUCTION 数据库更改。因此，在 Visual Studio 2012 中有“SQL 模式比较”工具，我只是想知道它是否不足以管理数据库中的所有更改以进行 PRODUCTION 开发？我可以将我的 {local} 数据库架构与 PRODUCTION 架构进行比较，然后简单地应用所有更改？

现在，我想问一下 Code First 迁移的意义何在？为什么要通过它来管理数据库中的所有变化？我能找到的唯一原因是允许执行各种“插入”和“更新”命令。但是我认为，如果数据库设计正确，则不需要执行这些命令。（这是另一个讨论的主题，所以我不想详细说明）。无论如何，我想问一下 - Code First 迁移相对于 Code First + Schema Compare 模式的真正优势是什么？

【问题讨论】：

标签： database entity-framework

【解决方案1】：

它简化了部署。如果您没有在代码中管理迁移，那么您将不得不在生产环境中手动运行适当的增量脚本。通过 EF 迁移，您可以将应用程序配置为在启动时自动将数据库迁移到最新版本。

通常，在 EF 迁移之前，如果您想自动执行此操作，您要么必须在自定义安装例程期间运行适当的 delta 脚本，要么将一些基础架构写入您的应用程序，以在代码中运行 delta 脚本。这需要知道当前的数据库版本，以便它知道要运行哪些脚本，您通常会在 DbVersion 表或类似的东西中拥有这些脚本。借助 EF 迁移，此管道已为您准备就绪。

使用迁移意味着模型和数据库更改的对齐是自动化的，因此更易于管理。

【讨论】：

感谢您的回答。您已经编写了“这需要知道当前的数据库版本”。事实上，当我使用 SQL Schema Comparer 时，我不需要了解有关生产数据库的任何此类信息。我只是调整它以满足我的本地主机数据库上定义的新模型结构。在更新数据库时，我真的看不出迁移相对于 SQL 模式比较方法的优势。无论如何 - 我将尝试在我的一个项目中使用它，看看它有什么特别之处。
在生产环境中，当您自动迁移时，您需要知道当前的数据库版本。如果部署到 10 个客户端会发生什么？ 20？ 100？如果客户端本身可以在应用程序启动时或通过“立即升级”菜单选项执行升级，会发生什么情况？
啊，现在我明白了！ :) 我只使用多租户数据库驱动的应用程序（主要是 Web 应用程序）。在这种情况下，我实际上只需要维护三个数据库（本地主机、测试和一个用于所有客户端的数据库）。在这种情况下，我可以使用 SQL Schema Compare 工具（我猜）。但是，如果应用程序是单租户，那么像 Code First Migrations 这样的功能确实可以显着简化部署。谢谢！