Andmete migreerimise süsteemide võrdlemine ja valimine
Andmete mudel arenduse käigus kätkeb endas muutumisvõimet ning mingil hetkel ei vasta see enam andmebaasile. Loomulikult on võimalik andmebaas kustutada, mille järel ORM loob uue versiooni, mis oleks mudeliga kooskõlas, kuid selline protseduur tooks kaasa olemasolevate andmete kaotuse. Seega on migratsioonisüsteemi funktsiooniks muuta schéma, et sünkroniseerida see rakenduse andmete mudeliga ilma olemasolevaid andmeid kaotamata.
Selles artiklis soovime käsitleda erinevaid tööriistu andmebaasimigreerimise haldamiseks. Loodame, et see ülevaade on kasulik arendajatele, kes seisavad silmitsi sellise valikuga.
Ülesanne
Meie ettevõttes käib aktiivne järgmise põlvkonna toote - Docs Security Suite (DSS) - arendamine. Serveri osa on kirjutatud .Net Core'is, nii et andmebaasina kasutatakse vastavalt Entity Framework Core'i. Rakenduse projekteerimisel kasutame lähenemist Code First.
Rakenduse domeenimudeli loomine toimub mitme arendaja üheaegsel osalusel – igaühel on vastutus oma loogilise süsteemi osa eest.
Eelmises DSS-i põlvkonnas kasutati migratsioonihalduse süsteemina klassikalisi Entity Framework Migrations (EF 6). Siiski, sellele on olnud mõned kriitilised märkused, peamine neist oli, et EF-il puudub mõistlik lähenemine versioonikonfliktide lahendamiseks. See fakt muretseb meid siiani vigade parandamise käigus toetuse raames, seetõttu otsustasime uurida alternatiivseid variante.
Arutelude tulemusena kujunesid välja järgmised nõuded migratsioonihalduse süsteemile:
- Toetage erinevaid andmebaasi haldurid. Oluline on MS SQL Server, PostgreSQL, Oracle, kuid potentsiaalselt on võimalik kasutada ka muid.
- Töö ORM-iga. Esialgu oli plaanis kasutada EF Core'i, kuid projekteerimise etapis olime valmis uurima ka muid ORM-e.
- Migratsioonide automaatne genereerimine. Arvestades Code First arendust, sooviksime vältida vajadust migratsioonide "käsitsi kirjutamise" järele.
- Versioonikonfliktid. Jaotatud arendamise tingimustes võib EF Core konfliktselt kokku kukkuda merge'eerimisel. See muutub tõsiseks probleemiks, kuna rakenduse erinevaid osi loovad erinevad arendajad ja seetõttu kulub igale konfliktile palju aega.
- Arendatud dokumentatsioon ja tugi. Siin, meie arvates, ei vaja selgitused
- Tasuta. Kriteerium on tingimuslik, kuna me olime valmis arvestama ka mitte liiga kallite süsteemidega või kallite, kuid mugavatega
Väikese uuringu tulemuste põhjal leiti ja tunnistati soovitavaks järgmised variandid:
- EF Core Migrations
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
Nüüd veidi põhjalikumalt
Muidugi, see oli esimene ja peamine valik. Kohalik tööriist, mis töötab kastist välja ilma igasuguste tantsudeta. Suur hulk dokumentatsiooni, ametlikku ja mitte nii ametlikku, lihtsus jne. Siiski, tõstatatud kaebused klassikalise EF-i vastu kehtivad täiesti ka EF Core'i puhul.
Seega on EF Core jaoks välja toodud eelised:
- Microsofti tugi, dokumentatsioon, sealhulgas vene keeles, tohutu kogukond
- Migreerimiste automaatne genereerimine CodeFirst'i põhjal
- Kuna EF 6-s ei hoita EF Core'is enam andmebaasi snapshot'i. EF Core'is töötades Code First'i puhul ei ole nüüd enam vajalik andmebaasi seadistamine
- Kuna lähtume Code First'ist – on võimalus hallata ühte migratsiooni kõigi nõutud andmebaasi juurdepääsu pakkujate jaoks
- Pakujate osas – toetatakse nii PostgreSQL-i kui ka Oracle'i jne, isegi MS SQL Serverit :)
Ja ka miinused:
- Konfliktide lahendamine on jääne sama tasemele. On vajalik üles ehitada migratsioonide järjestus ja uuendada andmebaasi snapshot'e
- Sõltuvus mudelitest, mille põhjal migratsioonid genereeritakse
DbUp
DbUp on .NET raamatukogu, mis installitakse NuGet'i kaudu ja aitab SQL Serveris muudatusi rakendada. See jälgib, milliseid muudatusskripte on juba teostatud ja käivitab need, mis on vajalikud andmebaasi uuendamiseks. Raamatukogu kasvas välja avatud lähtekoodiga blogiplatvormi projektist ASP.NET-is ja on loodud MIT litsentsi alusel, kood asub GitHub'is. Migratsioonid on kirjeldatud T-SQL abil.
Millised on eelised:
- Toetab suurt hulka andmebaasi haldamise süsteeme (MS SQL Server, PostgreSQL, MySQL)
- Kuna skripte kirjutatakse T-SQL-is, näevad nad üsna lihtsad välja
- Konflikte lahendatakse samuti SQL-i abil
Ja miinused:
- Rikkaliku toega andmebaasi haldamise süsteemide hulgas ei ole Oracle'i
- Ei suhelda ORM-idega
- T-SQL skriptide käsitsi kirjutamine ei ole see, mille poole me püüelnud oleme
- Dokumentatsioon ja kogukond ei ole just parimad, kuigi SQL-skriptide kirjutamise tingimustes võivad need olla ka vajalikud.
RoundhousE
See migrationi haldamise tööriist, mis on litsenseeritud Apache 2.0 alusel, töötab T-SQL migratsioonide mootoril nagu eelmine. Tundub, et arendajad pöörasid rohkem tähelepanu tehniliste probleemide lahendamisele DBMS-i toetamise osas kui mugava arendusprotsessi loomisele.
Plussid:
- Toetatakse vajalikke andmebaasimudeleid (sealhulgas Oracle'i)
Miinused:
- Oracle (nagu ka meile mitteaktuaalne Access) ei ole toetatud .NET Core'is, ainult .NET Full Framework'is
- Ei tööta ORM-iga
- Dokumentatsiooni on veel vähem kui eelmisel tööriistal
- Taas – migratsioonid kirjutatakse skriptidena
ThinkingHome.Migrator
Tööriist andmebaasi skeemi versioonide migratsiooniks .NET Core'i platvormile, litsenseeritud MIT alusel. .
Plussid:
- Suunatud .NET Core'ile
- On rakendatud haruliste migratsioonide järjestust
- On rakendatud migratsioonide logimine
Miinused:
- Viimane värskendus – aasta tagasi. Tundub, et projekt ei ole enam toetatud
- Oracle'i tugi puudub (artiklis on märgitud, et see on tingitud stabiilse rakenduse puudumisest .NET Core'i jaoks – kuid see oli aasta tagasi)
- Puudub migratsioonide automaatne genereerimine
Kokkuvõttes tundub projekt olevat paljutõotav, eriti kui see oleks arenenud, kuid me pidime siin ja praegu otsustama.
Fluent Migrator
Kõige populaarsem migratsioonitööriist, millel on suur hulk austajaid. Litsenseeritud Apache 2.0 alusel. Kirjelduses on märgitud, et see on .NET-i migratsiooniplatvorm, sarnane Ruby on Rails Migrations'iga. Andmebaasi skeemi muutusi kirjeldavad C# klassid.
Siin on mõned plussid:
- Toetatakse vajalikke andmebaasimudeleid
- Toetatakse .NET Core'i
- Suur ja arenenud kogukond
- Migratsioonide konfliktid lahendatakse järjestikku – migratsioonidele antakse täitmisjärjekord. Lisaks, kui tekib konflikt ühe entiteedi ümber, lahendatakse selle ühendamine sama põhimõtte kohaselt nagu muus koodis
- On profiilid, mis täidetakse pärast migratsiooni edukat sooritamist ja võivad sisaldada teenusfunktsioone. Viimane värskendus oli kuu aega tagasi, st projekt elab
Mis puutub miinustesse, siis siin:
- Puudub migratsioonide automaatne genereerimine
- Puudub seos EF mudelitega
- Puuduvad andmebaasi seisaku pildid
Kuidas oli meie valik?
Kõige kuumemad arutelud käisid kahe parameetri ümber – migreerimise automaatgeneratsioon ja arusaadavat lahendust konfliktide lahendamiseks. Ülejäänud tegurid häirisid oluliselt vähem. Lõppkokkuvõttes otsustas meeskond arutelu käigus kasutada uues projektis Fluent Migratorit. Konfliktide lahendamine toob pikemas perspektiivis palju rohkem eeliseid.
Järeldused
Muidugi pole ideaalseid tööriistu. Seetõttu tuli meil prioriteedid paika panna meie „soovide” seas. Siiski võivad teistele meeskondadele ja muudele ülesannetele olla otsustavad muud tegurid. Lootame, et see artikkel aitab teil valiku teha.
Allikas: habr.com
