管理实体框架迁移

Question

我正在使用 Entity Framework 开发一个多租户 Web 应用程序，该项目正在积极开发中，这个过程可能需要一两年的时间。我使用Migrations 管理数据库更改、添加新表和子系统、管理数据库triggers、播种默认数据等。添加新租户时也会使用它们，每个客户可能有几个不同的数据库，并且应用程序能够使用migrations 构建每个数据库。

但有一个问题，管理更改和保持迁移干净变得越来越难。虽然我们构建的系统不到 10%，但我最终完成了 50 多个迁移，并且花了几个小时将它们平铺成三到四个逻辑迁移。

这种方法还有另一个问题：破坏性更改。例如，当我使用view 时，向主表添加一个字段并不会更新视图等等。

你知道解决这些问题的方法吗？您使用什么方法让您的应用能够在您仍在开发它的同时构建其数据库，并且它会经常更改。

Answer 1

您是否有一个或一个millino迁移并不重要。应用迁移时，您可以设置目标迁移，所有迁移操作都作为单个执行。

您可以通过在包管理器控制台中运行 get-help update-database 来检查 Update-Database 文档。这些是可能的参数：

更新数据库 [-SourceMigration ] [-TargetMigration ] [-Script] [-Force] [-ProjectName ] [-StartUpProjectName ] [-ConfigurationTypeName ] [-ConnectionStringName ] [-AppDomainBaseDirectory ] []

更新数据库 [-SourceMigration ] [-TargetMigration ] [-Script] [-Force] [-ProjectName ] [-StartUpProjectName ] [-ConfigurationTypeName ] -ConnectionString -ConnectionProviderName [-AppDomainBaseDirectory ] []

如果您指定目标迁移，-Script 您将看到所有包含的迁移创建一个 SQL 脚本来更新数据库。如果您不指定该选项，脚本将被发送到数据库服务器（在项目的连接字符串中）。

如果不指定目标迁移，则会将数据库迁移到最新的迁移。

这回答了您问题的第一部分。您不必担心进行一次、一百次或无数次迁移。而且没有什么比“逻辑迁移”更重要的了。

关于你问题的第二部分，也没有任何问题。如果您需要在应用程序中进行修改，例如向表中添加列，则应该使更改解决方案范围广，即修改数据库（通过使用迁移）并更新解决方案代码以支持新列，即更新业务逻辑、实体、视图以及解决方案中的任何相关元素。至此，您有了一个稳定的版本。如果您部署此版本，并将数据库更新到最新的迁移，它将正常工作，而不会发生“重大更改”。因此，只要您的代码中有一个稳定版本，您就必须给它一个版本号，以便您可以部署该版本号。每个版本都将具有兼容的代码和迁移。您应该使用版本控制系统或任何其他方法来保持稳定的版本。

当然，如果您修改了数据库，并且代码不兼容（例如，您从表中删除了一个列，而您的代码引用了该列），如果您尝试部署它，它将无法工作。因此，您只需要小心创建稳定版本，并仅在它们处于该状态时使用版本号标记它们。

我有一个应用程序，它具有“更新到最新迁移”数据库初始化程序，并且，每当我向应用程序部署升级（甚至降级）时，它都能完美运行。唯一的要求是部署的版本是稳定的。