数据迁移系统的比选
数据模型在开发过程中往往会发生变化，到了某个时候就不再对应于数据库了。 当然，可以删除数据库，然后ORM将创建一个与模型匹配的新版本，但这个过程会导致现有数据的丢失。 因此，迁移系统的功能是确保在模式更改时与应用程序中的数据模型同步，而不会丢失现有数据。
在本文中，我们将了解用于管理数据库迁移的各种工具。 我们希望这篇评论对面临类似选择的开发人员有用。
任务
我们公司目前正在积极开发下一代产品——Docs Security Suite (DSS)。 服务器部分采用.Net Core编写，并使用Entity Framework Core作为DBMS。 在设计应用程序时，我们使用“代码优先”方法。
应用程序域模型由多个开发人员同时创建 - 每个开发人员负责自己的系统逻辑部分。
上一代DSS使用经典的Entity Framework Migrations（EF 6）作为迁移管理系统。 然而，针对它的一些抱怨已经积累起来，主要的抱怨是 EF 缺乏解决版本冲突的明智方法。 在修复错误作为支持的一部分时，这一事实仍然让我们感到不安，因此我们决定考虑其他选择。
经过讨论，形成了迁移管理系统的以下需求：
- 支持各种 DBMS。 需要 MS SQL Server、PostgreSQL、Oracle，但也可以使用其他
- 使用 ORM。 最初计划使用 EF Core，但在设计阶段我们准备考虑其他 ORM
- 自动生成迁移。 考虑到Code First的开发，我希望避免需要“手写”迁移
- 版本冲突。 在分布式开发环境中，合并时，EF Core 可能会出现冲突。 这成为一个严重的问题，因为应用程序的不同部分是由不同的开发人员创建的，因此您必须在每个部分上花费大量时间
- 高级文档和支持。 在我们看来，这里不需要解释
- 自由的。 该标准是有条件的，因为系统不是很昂贵或昂贵，但在便利性方面是理想的，我们也准备考虑
经过一些研究，发现以下选项值得考虑：
- EF Core 迁移
- 数据库备份
- 圆屋E
- ThinkingHome.Migrator
- 流利的迁移器
现在有更多细节
自然，这是第一个也是主要的选择。 一种原生乐器，开箱即用，无需摆弄手鼓。 大量的文档、官方的与非官方的、简单性等等。 然而，对经典 EF 的抱怨也与 EF Core 相关。
因此，EF Core 的优势就凸显出来了：
- Microsoft 支持、文档（包括俄语）、庞大的社区
- 基于CodeFirst自动生成迁移
- 与 EF 6 相比，EF Core 不再存储数据库的快照。 在 Code First 中使用 EF Core 时，不再需要部署数据库
- 由于我们从 Code First 开始，因此可以对所有必需的数据访问提供商进行一次迁移
- 关于提供商，支持 PostgreSQL、支持 Oracle 等等，甚至还支持 MS SQL Server
还有缺点：
- 冲突解决保持在同一水平。 有必要对迁移进行排序并更新数据库快照
- 对生成迁移的模型的依赖性
数据库备份
DbUp 是一个由 NuGet 安装的 .NET 库，有助于将更改推送到 SQL Server。 它跟踪已执行的更改脚本并运行更新数据库所需的脚本。 该库源自 ASP.NET 上的一个开源博客引擎项目，并在 MIT 许可下存在，代码位于 GitHub 上。 使用 T-SQL 描述迁移。
有什么优点：
- 支持大量 DBMS（MS SQL Server、PstgreSQL、MySQL）
- 由于脚本是用 T-SQL 编写的，因此看起来非常简单
- 冲突也可以使用 SQL 解决
以及缺点：
- 支持的 DBMS 多种多样，但 Oracle 并不是其中之一
- 不与 ORM 交互
- 手动编写 T-SQL 脚本并不是我们的目标
- 文档和社区马马虎虎，尽管就编写 SQL 脚本而言它们可能不是必需的。
圆屋E
与前一个迁移管理工具一样，该迁移管理工具在 Apache 2.0 许可证下分发，在 T-SQL 迁移引擎上运行。 显然，开发人员优先考虑解决有关 DBMS 支持的技术问题，而不是创建舒适的开发流程。
优点：
- 支持必要的DBMS（包括Oracle）
缺点：
- .NET Core 不支持 Oracle（以及 Access，这与我们无关），仅支持 .NET Full Framework
- 不适用于 ORM
- 文档比以前的工具还要少
- 再次强调——迁移是由脚本编写的
ThinkingHome.Migrator
用于将版本化数据库架构迁移到 .NET Core 平台的工具，根据 MIT 许可证分发。 .
优点：
- 专为 .NET Core 设计
- 实现了迁移的分支序列
- 实施迁移日志记录
缺点：
- 上次更新是在一年前。 显然该项目不受支持
- 不受 Oracle 支持（文章指出这是由于 .NET Core 缺乏稳定的实现 - 但这是一年前的事了）
- 没有自动生成迁移
总体而言，该项目看起来很有前途，特别是如果它要开发的话，但我们现在需要做出决定。
流利的迁移器
最受欢迎的迁移工具，拥有大量粉丝。 根据 Apache 2.0 许可证分发。 正如描述中所述，它是.NET 的迁移框架，类似于 Ruby on Rails 迁移。 对数据库架构的更改在 C# 类中描述。
这里有以下优点：
- 支持所需的 DBMS
- .NET 核心支持
- 大型发达社区
- 迁移之间的冲突按顺序解决——指定迁移的执行顺序。 此外，如果一个实体出现冲突，则在合并代码时，将以与其余代码相同的方式解决冲突
- 成功迁移后会执行一些配置文件。 并且可以承载服务功能，最后一次更新是一个月前，也就是项目存活了
至于缺点，它们是：
- 没有自动生成迁移
- 与 EF 型号无连接
- 没有数据库快照
我们的选择是什么？
激烈的争论围绕着两个参数——自动生成迁移和合理解决冲突。 其他因素就不那么可怕了。 结果，根据讨论的结果，团队决定在新项目中使用Fluent Migrator。 因为解决了未来的矛盾会带来更多的好处。
发现
当然，没有完美的工具。 所以我们必须优先考虑我们的“想要”才能做出选择。 然而，对于其他团队和其他任务来说，其他因素可能是决定性的。 我们希望这篇文章能帮助您做出选择。
来源： habr.com