管理实体框架迁移

Question

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

但是，有一个问题，管理变更和保持迁移干净变得越来越困难。 虽然我们只构建了不到10％的系统，但最终我进行了50多次迁移，并且花了几个小时才将它们划分为三个或四个逻辑迁移。

这种方法还有另一个问题：打破变化。 例如，当我使用view ，将一个字段添加到主表中不会更新该视图，等等。

您知道解决这些问题的任何方法吗？ 在仍在开发应用程序时，您将使用哪种方法使其应用程序能够构建其数据库，并且该应用程序会经常更改。

Answer 1

迁移一次或迁移一次都没关系。 应用迁移时，可以设置目标迁移，并且所有迁移操作都作为一个执行。

您可以通过在程序包管理器控制台中运行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脚本来更新数据库。 如果未指定该选项，则脚本将发送到数据库服务器（在项目的连接字符串中）。

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

这回答了您问题的第一部分。 您不必担心迁移一次，一百或一千亿。 而且没有“逻辑迁移”之类的东西。

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

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

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