Compararea și selectarea sistemelor de migrare a datelor
Modelul de date din procesul de dezvoltare are tendința de a se schimba, iar într-un anumit moment acesta nu mai corespunde bazei de date. Sigur, baza de date poate fi ștearsă, iar ORM va crea o nouă versiune care va corespunde modelului, dar o astfel de procedură va duce la pierderea datelor existente. Astfel, funcția sistemului de migrare se reduce la sincronizarea schemei cu modelul de date din aplicație fără pierderea datelor existente.
În cadrul acestui articol, ne propunem să discutăm diferite instrumente pentru gestionarea migrațiilor bazelor de date. Sperăm că această prezentare va fi utilă dezvoltatorilor care se confruntă cu o astfel de alegere.
Sarcină
Compania noastră este acum angajată într-o dezvoltare activă a generației următoare a produsului – Docs Security Suite (DSS). Partea serverului este scrisă în .Net Core, iar ca SGBD este utilizat Entity Framework Core. În proiectarea aplicației, ne folosim de abordarea Code First.
Modelul domenial al aplicației este creat de mai mulți dezvoltatori simultan – fiecare răspunzând de partea sa logică a sistemului.
În generația anterioară a DSS, pentru sistemul de gestionare a migrațiilor s-a utilizat clasicul Entity Framework Migrations (EF 6). Totuși, s-au acumulat unele nemulțumiri, cea mai importantă fiind că EF nu dispune de o abordare rezonabilă pentru soluționarea conflictelor de versiuni. Acest lucru ne afectează și acum în cadrul bug-fixing-ului pentru suport, așa că s-a decis să explorăm opțiuni alternative.
În urma discuțiilor, s-au formulat următoarele cerințe pentru sistemul de gestionare a migrațiilor:
- Suport pentru diverse SGBD-uri. Neapărat MS SQL Server, PostgreSQL, Oracle, dar este posibilă utilizarea și altora.
- Lucrul cu ORM. Inițial s-a presupus utilizarea EF Core, dar în etapa de proiectare erau deschiși și la alte ORM-uri.
- Generarea automată a migrațiilor. Având în vedere dezvoltarea Code First, ne-am dori să evităm necesitatea de a scrie manual migrațiile.
- Conflictele de versiuni. În condițiile unei dezvoltări distribuite, la îmbinarea codului, EF Core poate întâmpina probleme din cauza conflictelor. Aceasta devine o problemă semnificativă, deoarece diferite părți ale aplicației sunt create de diferiți dezvoltatori, ceea ce duce la un consum mare de timp pentru fiecare.
- Documentație și suport bine dezvoltate. Aici, nu credem că sunt necesare explicații.
- Gratuity. Este un criteriu condiționat, deoarece nu am fost împotriva sistemelor care sunt foarte ieftine sau, dimpotrivă, scumpe, dar confortabile, pe care am fost dispuși să le considerăm.
În urma unei cercetări minore, au fost identificate și recunoscute următoarele opțiuni ca fiind dorite pentru a fi considerate:
- Migrații EF Core
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
Și acum, câteva detalii suplimentare
Desigur, acesta a fost prima și principală opțiune. Un instrument nativ, care funcționează din cutie fără a necesita trucuri. O mare cantitate de documentație, oficială și neoficială, ușurință etc. Totuși, pretențiile aduse clasicului EF rămân actuale și pentru EF Core.
Astfel, pentru EF Core, s-au evidențiat avantajele:
- Suport Microsoft, documentație, inclusiv în limba română, o comunitate uriașă.
- Generare automată a migrațiilor pe baza CodeFirst.
- Spre deosebire de EF 6, în EF Core nu se mai stochează o captură a bazei de date. Când se lucrează cu EF Core în Code First, nu mai este obligatorie desfășurarea bazei de date.
- Deoarece pornim de la Code First, existe posibilitatea de a avea o singură migrație pentru toți furnizorii necesari de acces la date.
- În ceea ce privește furnizorii — sunt susținute atât PostgreSQL, cât și Oracle, etc., și chiar — MS SQL Server :)
Și dezavantajele:
- Rezolvarea conflictelor a rămas la același nivel. Este necesar să se stabilească o secvență a migrațiilor și să se actualizeze capturile bazei de date.
- Dependință de modelele pe baza cărora au fost generate migrațiile.
DbUp
DbUp este o bibliotecă .NET, care se instalează prin NuGet și ajută la aplicarea modificărilor pe SQL Server. Aceasta urmărește ce scripturi de modificări au fost deja executate și rulează acelea care sunt necesare pentru actualizarea bazei de date. Biblioteca a evoluat dintr-un proiect de motor de bloguri open-source pe ASP.NET și există sub licența MIT, iar codul este disponibil pe GitHub. Migrațiile sunt descrise folosind T-SQL.
Care sunt avantajele?
- Suport pentru un număr mare de SGBD-uri (MS SQL Server, PostgreSQL, MySQL).
- Deoarece scripturile sunt scrise în T-SQL, acestea arată destul de simplu.
- Conflictele sunt de asemenea rezolvate folosind SQL.
Iar dezavantajele:
- În ciuda diversității de SGBD-uri supportate, Oracle nu face parte din acestea.
- Nu interacționează cu ORM.
- Scrierea scripturilor în T-SQL pe „bazele de mâini” – nu este ceea ce ne-am dorit.
- Documentația și comunitatea sunt destul de slabe, deși în contextul scrierii scripturilor SQL, poate că nu sunt necesare.
RoundhousE
Acest instrument de gestionare a migrațiilor, distribuit sub licența Apache 2.0, precum și precedentul, funcționează pe motorul de migrații T-SQL. Se pare că dezvoltatorii s-au concentrat pe soluționarea problemelor tehnice legate de suportul pentru SGBD, mai degrabă decât pe crearea unui proces de dezvoltare confortabil.
Pro:
- Suportă SGBD-urile necesare (inclusiv Oracle)
Dezavantaje:
- Oracle (precum și Access, care nu este relevant pentru noi) nu este suportat pe .NET Core, doar pe .NET Full Framework
- Nu funcționează cu ORM
- Documentația este și mai puțină decât la instrumentul precedent
- Din nou - migrațiile sunt scrise în scripturi
ThinkingHome.Migrator
Instrument pentru migrarea versiunii schemei bazei de date pe platforma .NET Core, distribuit sub licența MIT. .
Pro:
- Proiectat pentru .NET Core
- A fost implementată o secvență branșată de migrații
- A fost implementat un sistem de jurnalizare a migrațiilor
Dezavantaje:
- Ultima actualizare a fost acum un an. Se pare că proiectul nu mai este susținut
- Nu suportă Oracle (în articol se menționează că acest lucru se datorează lipsei unei implementări stabile pentru .NET Core - dar asta a fost acum un an)
- Lipsește generarea automată a migrațiilor
În general, proiectul pare promițător, în special dacă ar fi evoluat, dar ne-am vărsat să luăm o decizie aici și acum.
Fluent Migrator
Cel mai popular instrument de migrare, având o mare armată de fani. Este distribuit sub licența Apache 2.0. Așa cum este indicat în descriere, este o platformă de migrare pentru .NET, similară cu Ruby on Rails Migrations. Modificările schemei Bazei de Date sunt descrise în clase scrise în C#.
Aici sunt avantaje:
- Suport pentru SGBD-urile necesare
- Suport pentru .NET Core
- O comunitate mare și dezvoltată
- Conflictele migrațiilor sunt rezolvate în mod secvențial - migrațiile au un ordonare de realizare specificată. În plus, dacă apare un conflict în jurul unei entități, soluționarea în merge-ul codului este realizată la fel ca în restul codului
- Există profile care se execută după succesul migrației. Și pot purta funcții de serviciu. Ultima actualizare a fost acum o lună, așadar proiectul este activ.
Cât despre dezavantaje, acestea sunt:
- Lipsește generarea automată a migrațiilor
- Lipsește legătura cu modelele EF
- Nu există snapshot-uri pentru baza de date
Care a fost alegerea noastră?
Cele mai aprinse discuții s-au concentrat în jurul a două parametrii – generarea automată a migrațiilor și soluționarea conflictelor. Alte factori păreau mult mai puțin alarmanți. În cele din urmă, echipa a decis să folosească Fluent Migrator în noul proiect. Deoarece soluționarea conflictelor pe termen lung va aduce mult mai multe beneficii.
Conclusions
Desigur, nu există instrumente perfecte. De aceea, a trebuit să stabilim priorități în „dorințele” noastre. Totuși, pentru alte echipe și alte sarcini, alți factori pot fi decisivi. Sperăm ca acest articol să vă ajute să faceți o alegere.
Sursa: habr.com
