Compararea și selectarea sistemelor de migrare a datelor
Modelul de date tinde să se schimbe în timpul procesului de dezvoltare, iar la un moment dat nu mai corespunde bazei de date. Desigur, baza de date poate fi ștearsă, iar apoi ORM-ul va crea o nouă versiune care se va potrivi cu modelul, dar această procedură va duce la pierderea datelor existente. Astfel, funcția sistemului de migrare este de a se asigura că, în urma unei modificări de schemă, acesta este sincronizat cu modelul de date din aplicație fără a pierde datele existente.
În acest articol, am dori să analizăm diverse instrumente pentru gestionarea migrărilor bazelor de date. Sperăm că această recenzie va fi utilă dezvoltatorilor care se confruntă cu o alegere similară.
Sarcină
Compania noastră dezvoltă în prezent în mod activ următoarea generație de produse – Docs Security Suite (DSS). Partea de server este scrisă în .Net Core, iar Entity Framework Core este folosit ca SGBD. Când proiectăm o aplicație, folosim abordarea Code First.
Modelul domeniului aplicației este creat de mai mulți dezvoltatori în același timp - fiecare este responsabil pentru propria lor parte logică a sistemului.
Generația anterioară de DSS a folosit clasicul Entity Framework Migrations (EF 6) ca sistem de management al migrației. Cu toate acestea, s-au acumulat unele plângeri împotriva acestuia, principala fiind că EF nu are o abordare sănătoasă pentru rezolvarea conflictelor de versiuni. Acest fapt încă ne deranjează atunci când remediam erori ca parte a suportului, așa că am decis să luăm în considerare opțiuni alternative.
În urma discuției, s-au format următoarele cerințe pentru sistemul de management al migrației:
- Suport pentru diferite SGBD-uri. Sunt necesare MS SQL Server, PostgreSQL, Oracle, dar este posibil să se utilizeze altele
- Lucrul cu ORM. Inițial, a fost planificat să se utilizeze EF Core, dar în etapa de proiectare eram gata să luăm în considerare alte ORM-uri
- Autogenerare de migrații. Ținând cont de dezvoltarea Code First, aș dori să evit nevoia de a „scrie de mână” migrările
- Conflicte de versiuni. Într-un mediu de dezvoltare distribuit, la fuziune, EF Core poate suferi conflicte. Aceasta devine o problemă semnificativă, deoarece diferite părți ale aplicației sunt create de diferiți dezvoltatori, așa că trebuie să petreceți mult timp pentru fiecare
- Documentare avansată și suport. Aici, ni se pare, nu este nevoie de o explicație
- Gratuit. Criteriul este condiționat, deoarece sistemele nu sunt foarte scumpe sau scumpe, dar ideale în comoditate, am fost, de asemenea, gata să luăm în considerare
Ca urmare a unei mici cercetări, următoarele opțiuni au fost găsite și considerate de dorit pentru a fi luate în considerare:
- Migrații EF Core
- DBup
- RoundhouseE
- ThinkingHome.Migrator
- Migrator fluent
Și acum puțin mai multe detalii
Desigur, aceasta a fost prima și principala opțiune de ales. Un instrument nativ care funcționează din cutie fără a se juca cu o tamburină. O cantitate mare de documentație, oficială și nu așa, simplitate etc. Cu toate acestea, plângerile făcute cu privire la EF clasic sunt, de asemenea, destul de relevante pentru EF Core.
Astfel, sunt evidențiate avantajele pentru EF Core:
- Asistență Microsoft, documentație, inclusiv în limba rusă, comunitate uriașă
- Generarea automată a migrațiilor bazate pe CodeFirst
- În comparație cu EF 6, EF Core nu mai stochează un instantaneu al bazei de date. Când lucrați cu EF Core în Code First, nu mai este necesar să implementați o bază de date
- Deoarece dansăm de la Code First, este posibil să efectuăm o singură migrare către toți furnizorii de acces la date necesari
- În ceea ce privește furnizorii, PostgreSQL este suportat, Oracle este suportat etc., etc. și chiar și MS SQL Server
Și, de asemenea, dezavantajele:
- Rezolvarea conflictelor a rămas la același nivel. Este necesar să secvențați migrațiile și să actualizați instantaneele bazei de date
- Dependența de modelele pe care sunt generate migrațiile
DbUp
DbUp este o bibliotecă .NET care este instalată de NuGet și ajută la introducerea modificărilor în SQL Server. Acesta ține evidența scripturilor de modificare care au fost deja executate și le execută pe cele necesare pentru actualizarea bazei de date. Biblioteca a apărut dintr-un proiect pentru un motor de blogging open source pe ASP.NET și există sub o licență MIT, iar codul este pe GitHub. Migrațiile sunt descrise folosind T-SQL.
Care sunt avantajele:
- Suport pentru un număr mare de SGBD (MS SQL Server, PstgreSQL, MySQL)
- Deoarece scripturile sunt scrise în T-SQL, ele arată destul de simplu
- De asemenea, conflictele sunt rezolvate folosind SQL
Și contra:
- Cu toată varietatea de SGBD-uri acceptate, Oracle nu este unul dintre ele
- Nu interacționează cu ORM
- Scrierea manuală a scripturilor T-SQL nu este ceea ce ne-am propus
- Documentația și comunitatea sunt așa așa, deși în ceea ce privește scrierea scripturilor SQL, acestea ar putea să nu fie necesare.
RoundhouseE
Acest instrument de gestionare a migrației, distribuit sub licența Apache 2.0, ca și precedentul, rulează pe motorul de migrare T-SQL. Aparent, dezvoltatorii au prioritizat rezolvarea problemelor tehnice privind suportul DBMS, mai degrabă decât crearea unui proces de dezvoltare confortabil.
Pro-uri:
- Suporta DBMS-ul necesar (inclusiv Oracle)
Contra:
- Oracle (precum și Access, care este irelevant pentru noi) nu este acceptat pe .NET Core, doar pe .NET Full Framework
- Nu funcționează cu ORM
- Există chiar mai puțină documentație decât instrumentul anterior
- Din nou – migrațiile sunt scrise prin scripturi
ThinkingHome.Migrator
Un instrument pentru migrarea schemei bazei de date cu versiuni către platforma .NET Core, distribuită sub licența MIT. .
Pro-uri:
- Proiectat pentru .NET Core
- Am implementat o secvență de ramificare a migrațiilor
- Jurnalul de migrare a fost implementat
Contra:
- Ultima actualizare acum un an. Se pare că proiectul nu este susținut
- Nu este acceptat de Oracle (articolul afirmă că acest lucru se datorează lipsei unei implementări stabile pentru .NET Core - dar aceasta este acum un an)
- Fără generare automată de migrații
În general, proiectul pare promițător, mai ales dacă ar fi să se dezvolte, dar trebuia să luăm o decizie aici și acum.
Migrator fluent
Cel mai popular instrument de migrare cu o mare armata de fani. Distribuit sub licența Apache 2.0. După cum se menționează în descriere, este un cadru de migrare pentru .NET, similar cu Ruby on Rails Migrations. Modificările aduse schemei bazei de date sunt descrise în clasele C#.
Există avantaje aici:
- Suport pentru DBMS necesar
- Suport .NET Core
- Comunitate mare dezvoltată
- Conflictele dintre migrări sunt rezolvate secvenţial — este specificată ordinea de execuţie a migraţiilor. În plus, dacă apare un conflict în jurul unei entități, la fuzionarea codului, acesta este rezolvat în același mod ca și în restul codului
- Există profiluri care sunt executate după o migrare reușită. Și pot transporta funcții de service.Ultima actualizare a fost acum o lună, adică proiectul este în viață
În ceea ce privește minusurile, iată-le:
- Fără generare automată de migrații
- Nicio legătură cu modelele EF
- Fără instantanee de bază de date
Care a fost alegerea noastră?
Dezbaterile aprinse s-au învârtit în jurul a doi parametri - generarea automată a migrațiilor și rezolvarea sănătoasă a conflictelor. Alți factori au fost mult mai puțin înspăimântători. Ca urmare, pe baza rezultatelor discuției, echipa a decis să folosească Fluent Migrator în noul proiect. Pentru că rezolvarea conflictelor în viitor va aduce mult mai multe beneficii.
Constatări
Desigur, nu există instrumente perfecte. Așa că a trebuit să acordăm prioritate „dorințelor” noastre de a face o alegere. Cu toate acestea, pentru alte echipe și alte sarcini, alți factori pot fi decisivi. Sperăm că acest articol vă va ajuta să faceți o alegere.
Sursa: www.habr.com