Adatmigrációs rendszerek összehasonlítása, kiválasztása
Az adatmodell a fejlesztési folyamat során hajlamos megváltozni, és egy ponton már nem felel meg az adatbázisnak. Természetesen az adatbázis törölhető, majd az ORM létrehoz egy új verziót, amely megfelel a modellnek, de ez az eljárás a meglévő adatok elvesztéséhez vezet. Így a migrációs rendszer feladata annak biztosítása, hogy egy sémaváltás eredményeként a meglévő adatok elvesztése nélkül szinkronizálódjon az alkalmazás adatmodelljével.
Ebben a cikkben az adatbázis-áttelepítések kezelésére szolgáló különféle eszközöket szeretnénk áttekinteni. Reméljük, hogy ez az áttekintés hasznos lesz azoknak a fejlesztőknek, akik hasonló választás előtt állnak.
Feladat
Cégünk jelenleg aktívan fejleszti a termék következő generációját – a Docs Security Suite-t (DSS). A szerver rész .Net Core nyelven íródott, és az Entity Framework Core DBMS-ként használatos. Egy alkalmazás tervezésekor a Code First megközelítést alkalmazzuk.
Az alkalmazási tartomány modelljét egyidejűleg több fejlesztő hozza létre – mindegyik felelős a saját logikai rendszerrészéért.
A DSS előző generációja a klasszikus Entity Framework Migrations-t (EF 6) használta migrációkezelő rendszerként. Néhány panasz azonban felgyülemlett ellene, a fő az, hogy az EF-től hiányzik az épelméjű megközelítés a verziókonfliktusok megoldására. Ez a tény még mindig felzaklat minket, amikor a támogatás részeként javítjuk a hibákat, ezért úgy döntöttünk, hogy alternatív lehetőségeket fontolgatunk.
A megbeszélés eredményeként a következő követelmények alakultak ki a migrációkezelő rendszerrel szemben:
- Különféle DBMS-ek támogatása. MS SQL Server, PostgreSQL, Oracle szükséges, de lehetséges, hogy másokat is használhat
- Munka az ORM-mel. Kezdetben az EF Core használatát tervezték, de a tervezési szakaszban készen álltunk más ORM-ek megfontolására.
- Áttelepítések automatikus generálása. Figyelembe véve a Code First fejlesztését, szeretném elkerülni a „kézírásos” migrációt
- Verzióütközések. Elosztott fejlesztői környezetben az egyesülés során az EF Core konfliktusoktól szenvedhet. Ez jelentős problémává válik, mivel az alkalmazás különböző részeit különböző fejlesztők hozzák létre, így sok időt kell szánni mindegyikre.
- Speciális dokumentáció és támogatás. Itt, úgy tűnik, nincs szükség magyarázatra
- Ingyenes. A kritérium feltételes, mivel a rendszerek nem túl drágák vagy drágák, de kényelmi szempontból ideálisak, készek voltunk arra is, hogy
Egy kis kutatás eredményeként a következő lehetőségeket találtuk és tartottuk megfontolandónak:
- EF Core Migrations
- DBup
- KerekházE
- ThinkingHome.Migrator
- Folyékony migrátor
És most egy kicsit részletesebben
Természetesen ez volt az első és legfontosabb választási lehetőség. Egy natív hangszer, amely a dobozból kivehető, anélkül, hogy a tamburával babrálna. Nagy mennyiségű dokumentáció, hivatalos és nem olyan, egyszerűség stb. A klasszikus EF-re vonatkozó panaszok azonban az EF Core-ra is nagyon relevánsak.
Így kiemeljük az EF Core előnyeit:
- Microsoft támogatás, dokumentáció, beleértve az orosz nyelvet is, hatalmas közösség
- Áttelepítések automatikus generálása a CodeFirst alapján
- Az EF 6-hoz képest az EF Core már nem tárol pillanatképet az adatbázisról. Amikor az EF Core-al dolgozik a Code First-ben, többé nem szükséges adatbázist telepíteni
- Mivel a Code Firsttől táncolunk, lehetséges egyetlen migráció az összes szükséges adathozzáférési szolgáltatóhoz
- A szolgáltatókat illetően a PostgreSQL támogatott, az Oracle támogatott stb., stb., sőt még az MS SQL Server is
És a hátrányai is:
- A konfliktusmegoldás változatlan maradt. Szükséges az áttelepítések sorrendje és az adatbázis-pillanatképek frissítése
- Függőség azoktól a modellektől, amelyeken a migráció létrejön
DbUp
A DbUp egy .NET-könyvtár, amelyet a NuGet telepít, és segít a változtatások átküldésében az SQL Serverre. Nyomon követi, hogy mely változtatási szkriptek lettek már végrehajtva, és lefuttatja azokat, amelyek az adatbázis frissítéséhez szükségesek. A könyvtár az ASP.NET nyílt forráskódú blogolómotorjának projektjéből nőtt ki, és MIT licenc alatt létezik, a kód pedig a GitHubon található. A migráció leírása T-SQL használatával történik.
Mik az előnyök:
- Nagyszámú DBMS támogatása (MS SQL Server, PstgreSQL, MySQL)
- Mivel a szkriptek T-SQL-ben vannak írva, meglehetősen egyszerűnek tűnnek
- Az ütközéseket is SQL segítségével oldják meg
És a hátrányok:
- A támogatott DBMS-ek sokféleségével az Oracle nem tartozik ezek közé
- Nem működik együtt az ORM-mel
- A T-SQL-szkriptek kézi írása nem az, amire vágytunk
- A dokumentáció és a közösség olyan-olyan, bár az SQL-szkriptek írása szempontjából nem feltétlenül szükséges.
KerekházE
Ez az Apache 2.0 licenc alatt terjesztett migrációkezelő eszköz az előzőhöz hasonlóan a T-SQL migrációs motoron fut. Úgy tűnik, a fejlesztők a DBMS-támogatással kapcsolatos technikai problémák megoldását helyezték előtérbe, nem pedig egy kényelmes fejlesztési folyamatot.
Előnyök:
- Támogatja a szükséges DBMS-t (beleértve az Oracle-t is)
Hátrányok:
- Az Oracle (valamint a számunkra lényegtelen Access) nem támogatott a .NET Core-on, csak a .NET Full Framework-en
- ORM-mel nem működik
- Még kevesebb a dokumentáció, mint az előző eszköznél
- Ismételten: a migrációkat szkriptek írják
ThinkingHome.Migrator
Eszköz a verziószámú adatbázisséma áttelepítéséhez a .NET Core platformra, MIT licenc alatt terjesztve. .
Előnyök:
- .NET Core-hoz tervezték
- Elágazó migrációs sorozatot valósított meg
- Megvalósított migrációs naplózás
Hátrányok:
- Utoljára frissítve egy éve. A projekt nyilvánvalóan nem támogatott
- Az Oracle nem támogatja (a cikk szerint ez a .NET Core stabil megvalósításának hiánya miatt van - de ez egy éve)
- Nincs automatikus migráció generálása
Összességében a projekt ígéretesnek tűnik, különösen, ha fejlődne, de itt és most kellett döntést hoznunk.
Folyékony migrátor
A legnépszerűbb migrációs eszköz rajongók nagy seregével. Az Apache 2.0 licenc alatt terjesztve. Ahogy a leírásban is szerepel, ez egy .NET migrációs keretrendszer, hasonlóan a Ruby on Rails Migrationshez. Az adatbázisséma módosításait a C# osztályok írják le.
Itt vannak előnyei:
- A szükséges DBMS támogatása
- .NET Core támogatás
- Nagy fejlett közösség
- Az áttelepítések közötti ütközések szekvenciális feloldása – az áttelepítések végrehajtási sorrendje meg van adva. Ezen túlmenően, ha konfliktus merül fel egy entitás körül, akkor a kód egyesítésekor az ugyanúgy feloldódik, mint a kód többi részén.
- Vannak olyan profilok, amelyek sikeres migráció után futnak le. És szerviz funkciókat is hordozhatnak.A legutóbbi frissítés egy hónapja volt, vagyis él a projekt
Ami a mínuszokat illeti, itt vannak:
- Nincs automatikus migráció generálása
- Nincs kapcsolat az EF modellekkel
- Nincsenek adatbázis-pillanatképek
Mi volt a választásunk?
A heves viták két paraméter körül forogtak: a migráció automatikus generálása és a konfliktusok ésszerű megoldása. Más tényezők sokkal kevésbé voltak ijesztőek. Ennek eredményeként a megbeszélés eredményei alapján a csapat úgy döntött, hogy a Fluent Migratort használja az új projektben. Mert a konfliktusok megoldása a jövőben sokkal több haszonnal jár.
Álláspontja
Természetesen tökéletes eszközök nincsenek. Tehát fontossági sorrendbe kellett hoznunk a „kívánságainkat”, hogy választhassunk. Más csapatoknál és egyéb feladatoknál azonban más tényezők is döntőek lehetnek. Reméljük, hogy ez a cikk segít a választásban.
Forrás: will.com