数据迁移系统的比较和选择

数据迁移系统的比较和选择

开发过程中的数据模型具有更改的属性，并且在某些时候它不再与数据库相对应。 当然，可以删除数据库，然后ORM将创建一个与该模型相对应的新版本，但是这样的过程将导致现有数据的丢失。 因此，迁移系统的功能是确保由于更改方案而将其与应用程序中的数据模型同步，而不会丢失现有数据。

在本文中，我们将考虑用于管理数据库迁移的各种工具。 我们希望这篇评论对面临此选择的开发人员有用。

挑战赛

我们公司目前正在积极开发下一代产品Docs Security Suite（DSS）。 服务器部分写在.Net Core上，而Entity Framework Core分别用作DBMS。 在设计应用程序时，我们使用“代码优先”方法。

该应用程序的域模型是由多个开发人员同时创建的-每个开发人员都负责其自己的系统逻辑部分。

在上一代DSS中，经典的实体框架迁移（EF 6）被用作迁移管理系统。 但是，有人对此提出了一些要求，主要是EF缺乏解决版本冲突的明智方法。 当在支持框架内修复错误时，这一事实仍然使我们感到沮丧，因此决定考虑其他选择。

讨论的结果是，形成了对迁移管理系统的以下要求：

1. 支持各种DBMS。 强制性MS SQL Server，PostgreSQL，Oracle，但您可以潜在地使用其他
2. 使用ORM。 最初，应该使用EF Core，但是在设计阶段，其他ORM可以考虑使用
3. 自动生成迁移。 鉴于Code First的发展，我想避免需要“用笔绘画”
4. 版本冲突。 在具有合并功能的分布式开发环境中，EF Core可能在冲突中崩溃。 这成为一个严重的问题，因为应用程序的不同部分是由不同的开发人员创建的，因此您必须为每个应用程序花费大量时间。
5. 高级文档和支持。 在我们看来，这里不需要解释
6. 免费的。 有条件的标准，因为它不是很昂贵的系统，也不是很昂贵，但是在便利性方面很理想，我们也准备考虑

一项小型研究的结果是，发现以下选项，并认为值得考虑：

1. EF核心迁移
2. Dbup
3. RoundhousE
4. ThoughtHome.Migrator
5. 流利的移民

现在多一点

EntityFramework核心迁移

自然，这是选择的第一个也是主要的选择。 开箱即用的本地工具，无需铃鼓跳舞。 大量的文档，官方的，不是很简单，等等。 但是，提交给经典EF的声明与EF Core十分相关。

因此，EF Core的优势得以突出：

• Microsoft支持和文档，包括俄语，一个庞大的社区
• 基于CodeFirst的自动迁移
• 与EF 6相比，数据库快照不再存储在EF Core中。 在Code First中使用EF Core时，您不再需要部署数据库
• 由于我们是从Code First跳出来的，因此可以向所有必需的数据访问提供商进行一次迁移
• 关于提供程序-PostgreSQL，Oracle等，等等，甚至-MS SQL Server受支持

以及缺点：

• 解决冲突的水平保持不变。 有必要构建一系列迁移并更新数据库映像
• 依赖于生成迁移的模型

Dbup


dbup.imtqy.com

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脚本的上下文中可能不需要它们。

RoundhousE


github.com/chucknorris/roundhouse

与以前的许可证一样，此迁移管理工具在Apache 2.0许可下分发，可在T-SQL迁移引擎上运行。 显然，开发人员专注于解决有关DBMS支持的技术问题，而不是创建舒适的开发过程。

优点：

• 支持必要的DBMS（包括Oracle）

缺点：

• .NET Core不支持Oracle（以及与我们无关的Access），仅在.NET Full Framework中支持
• 不适用于ORM
• 与以前的工具相比，文档甚至更少
• 再次-迁移是用脚本编写的

ThoughtHome.Migrator



用于.NET Core平台的数据库架构的版本迁移的工具，该工具已根据MIT许可进行分发。 开发人员本人在大约一年前就写了最新版本 。

优点：

• 在.NET Core下锐化
• 已实施的迁移分支顺序
• 已实施的迁移日志

缺点：

• 最近更新-一年前。 显然，不支持该项目。
• Oracle不支持（本文指出这是由于缺少.NET Core的稳定实现-但这是一年前的事）
• 缺少自动生成的迁移

总的来说，该项目看起来很有希望，尤其是如果要开发的话，但我们需要在此时此地做出决定。

流利的移民


github.com/fluentmigrator/fluentmigrator

最受欢迎的迁移工具，拥有众多的粉丝。 根据Apache 2.0许可证分发。 如描述中所述，它是.NET的迁移平台，类似于Ruby on Rails迁移。 在C＃中的类中描述了对数据库模式的更改。

有优点：

• 支持必要的DBMS
• .NET Core支持
• 大型发达社区
• 迁移冲突按顺序解决-指示了迁移的执行顺序。 此外，如果在一个实体周围存在冲突，则在合并代码时，其解决方案的执行方式与其余代码相同
• 有成功迁移后运行的配置文件。 并且它们可以承载服务功能。最后一次更新是在一个月前，即项目在运行中

至于缺点，在这里：

• 缺少自动生成的迁移
• 与EF型号无关
• 没有数据库快照

我们的选择是什么？

最激烈的辩论围绕着两个参数-迁移的自动产生和合理的冲突解决。 其他因素吓得少得多。 结果，经过讨论，团队决定在新项目中使用Fluent Migrator。 对于将来解决冲突将带来很多好处。

结论

当然，没有完美的工具。 因此，我们必须优先选择“愿望清单”。 但是，其他因素对于其他团队和其他任务可能是决定性的。 我们希望本文能帮助您做出选择。