Adatmigrációs rendszerek összehasonlítása és kiválasztása

A model in the development process tends to change, and at some point, it no longer matches the database. Of course, the database can be deleted, and then the ORM will create a new version that corresponds to the model, but this procedure will result in the loss of existing data. Thus, the function of the migration system is to synchronize the schema with the data model in the application without losing existing data.
In this article, we would like to explore various tools for managing database migrations. We hope that this overview will be useful for developers faced with such choices.
Feladat
Our company is currently actively developing the next generation of the product – Docs Security Suite (DSS). The server side is being written in .Net Core, and we are accordingly using Entity Framework Core as the database management system. When designing the application, we use a Code First approach.
The domain model of the application is created by several developers simultaneously – each responsible for their logical part of the system.
In the previous generation of DSS, classic Entity Framework Migrations (EF 6) was used as the migration management system. However, it has accumulated some complaints, the main one being that EF lacks a reasonable approach to resolving version conflicts. This fact still troubles us during bug fixing in support, which is why a decision was made to consider alternative options.
As a result of the discussion, the following requirements were formed for the migration management system:
- Support for various DBMS. MS SQL Server, PostgreSQL, Oracle are mandatory, but potentially other databases can also be used.
- Work with ORM. Initially, EF Core was assumed for use, but during the design phase, we were open to considering other ORMs.
- Autogeneration of migrations. Given the development of Code First, we would like to avoid the need to "write migrations by hand".
- Version conflicts. In a distributed development environment, when merging, EF Core can fail due to conflicts. This becomes a significant problem since different parts of the application are created by different developers, requiring a lot of time spent on each merge.
- Fejlett dokumentáció és támogatás. Itt, úgy véljük, a magyarázatok nem szükségesek.
- Ingyenesség. A kritérium feltételes, mivel a nem túl drága rendszerek vagy drága, de kényelmes megoldások is szóba jöhetnek.
Egy kisebb kutatás eredményeként a következő lehetőségeket találták és ismerik el kívánatosnak a megfontolásra:
- EF Core Migrations
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
Most pedig egy kicsit részletesebben

Természetesen ez volt az első és fő választás. Natív eszköz, ami dobozból kihúzva működik, mindenféle trükközés nélkül. Nagy mennyiségű dokumentáció, hivatalos és nem hivatalos, egyszerűség stb. Azonban a klasszikus EF-hez feltett panaszok teljesen relevánsak az EF Core esetében is.
Így az EF Core-hoz a következő előnyök tartoznak:
- Microsoft támogatás, dokumentáció, többek között oroszul, hatalmas közösség.
- Migrációk automatikus generálása CodeFirst alapján.
- Összehasonlítva az EF 6-tal, az EF Core most már nem tárolja az adatbázis pillanatképet. Az EF Core használatakor a Code First-nél nem szükséges az adatbázis telepítése.
- Mivel a Code First-től indulunk – van lehetőség egy migrációt vezetni az összes szükséges adatbázis-hozzáférési szolgáltatóra.
- A szolgáltatók tekintetében – támogatja a PostgreSQL-t, Oracle-t stb., és még a MS SQL Server-t is.
És a hátrányok:
- A konfliktusok megoldása ugyanazon a szinten maradt. Meg kell állapítani a migrációk sorrendjét és frissíteni az adatbázis pillanatképet.
- Függőség a modellektől, amelyek alapján a migrációk generálódtak.
DbUp

A DbUp egy .NET könyvtár, amelyet a NuGet-en keresztül telepítenek, és segít a változások alkalmazásában a SQL Server-en. Nyomon követi, hogy mely változtatásokról van már szó, és végrehajtja azokat, amelyek szükségesek az adatbázis frissítéséhez. A könyvtár egy ASP.NET nyílt forráskódú blogmotor projektből nőtte ki magát, és MIT licenc alatt áll, a kódja GitHub-on található. A migrációkat T-SQL segítségével írják le.
Mik az előnyei:
- Számos DBMS támogatása (MS SQL Server, PostgreSQL, MySQL).
- Mivel a szkriptek T-SQL-ben íródnak, meglehetősen egyszerűek.
- A konfliktusokat SQL segítségével is megoldják.
A hátrányai:
- Annak ellenére, hogy számos DBMS támogatott, az Oracle nem tartozik közéjük.
- Nem működik együtt az ORM-mel.
- A T-SQL szkriptek „kézi” írása – nem az, amit el szeretnénk érni.
- A dokumentáció és a közösség nem éppen a legjobb, de SQL-scriptek írása közben talán nincs is szükségük ezekre.
RoundhousE

Ez a migrációs kezelés eszköz, az Apache 2.0 licenc alatt terjesztve, és hasonlóan az előzőhöz, T-SQL migrációs motoron működik. Úgy tűnik, hogy a fejlesztők a technikai problémák megoldására összpontosítottak az adatbázis-kezelők támogatásának terén, nem pedig a fejlesztési folyamat kényelmére.
Előnyök:
- Támogatja a szükséges adatbázis-kezelőket (beleértve az Oraclet is)
Hátrányok:
- Az Oracle (és az számunkra nem releváns Access) nem támogatott a .NET Core-on, csak a .NET Full Frameworkön.
- Nem működik ORM-mel
- A dokumentáció még kevesebb, mint az előző eszköznél
- Ismét – a migrációk scriptek írásával készülnek
ThinkingHome.Migrator
![]()
Ez egy verziókezelő migrációs eszköz az adatbázis séma számára a .NET Core platformhoz, az MIT licenc alatt terjesztve. .
Előnyök:
- A .NET Core-ra van optimalizálva
- Megvalósult az ágazatos migrációs folyamat
- A migrációk naplózása megvalósult
Hátrányok:
- Az utolsó frissítés egy éve volt. Úgy tűnik, a projekt nem támogatott
- Oracle nem támogatott (a cikkben említve van, hogy ez a .NET Core stabil megvalósításának hiánya miatt van – de ez egy éve volt)
- Nincs migrációk automatikus generálása
Összességében a projekt ígéretesen néz ki, különösen ha fejlődne, de itt és most kellett döntést hoznunk.
Fluent Migrator

A legnépszerűbb migrációs eszköz, nagy rajongótáborral. Az Apache 2.0 licenc alatt terjesztve. A leírás szerint ez egy migrációs platform a .NET számára, hasonló a Ruby on Rails migrációkhoz. Az adatbázis séma változásait C# osztályokban írják le.
Itt vannak az előnyök:
- A szükséges adatbázis-kezelők támogatása
- A .NET Core támogatása
- Nagy, fejlődő közösség
- A migrációs konfliktusokat sorban oldják meg – a migrációknak meg van adva a végrehajtási sorrendjük. Ezenkívül, ha konfliktus lép fel egy entitás körül, a kód egyesítésekor a megoldást ugyanúgy találják meg, mint a többi kódban.
- Vannak profilok, amelyek a migráció sikeres végrehajtása után futnak, és szolgáltatási funkciókat kínálhatnak. Az utolsó frissítés egy hónapja volt, tehát a projekt aktív.
Ami a hátrányokat illeti, itt van:
- Nincs migrációk automatikus generálása
- Nincs kapcsolat az EF modellekkel
- Nincsenek adatbázis pillanatképek
Mi volt a választásunk?

A leghevesebb viták a migrációk automatikus előállítása és a konfliktusok ésszerű megoldása körül zajlottak. Más tényezők sokkal kevésbé aggasztották a csapatot. Végül a csapat döntése az új projektben a Fluent Migrator használata lett. Mivel a konfliktusok megoldása a jövőben sokkal több előnyt fog hozni.
Következtetések
Természetesen nincsenek tökéletes eszközök. Így nekünk is prioritásokat kellett felállítanunk az elvárásaink között. Azonban más csapatok és más feladatok esetén más tényezők lehetnek döntőek. Reméljük, hogy ez a cikk segít a választásban.
Forrás: habr.com
