数据迁移系统的比选
数据模型在开发过程中往往会发生变化,到了某个时候就不再对应于数据库了。 当然,可以删除数据库,然后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