Duomenų perkėlimo sistemų palyginimas ir parinkimas
Duomenų modelis kūrimo proceso metu linkęs keistis ir tam tikru momentu nebeatitinka duomenų bazės. Žinoma, duomenų bazę galima ištrinti, o tada ORM sukurs naują versiją, kuri atitiks modelį, tačiau ši procedūra sukels esamų duomenų praradimą. Taigi, perkėlimo sistemos funkcija yra užtikrinti, kad dėl schemos pakeitimo ji būtų sinchronizuojama su duomenų modeliu programoje neprarandant esamų duomenų.
Šiame straipsnyje norėtume pažvelgti į įvairius duomenų bazių perkėlimo valdymo įrankius. Tikimės, kad ši apžvalga bus naudinga kūrėjams, susiduriantiems su panašiu pasirinkimu.
Užduotis
Mūsų įmonė šiuo metu aktyviai kuria naujos kartos produktą – Docs Security Suite (DSS). Serverio dalis parašyta .Net Core, o Entity Framework Core naudojama kaip DBVS. Kurdami programą naudojame „Code First“ metodą.
Programos domeno modelį vienu metu kuria keli kūrėjai – kiekvienas yra atsakingas už savo loginę sistemos dalį.
Ankstesnės kartos DSS kaip migracijos valdymo sistemą naudojo klasikinę objektų sistemos perkėlimą (EF 6). Tačiau dėl jos susikaupė keletas skundų, kurių pagrindinis yra tai, kad EF trūksta protingo požiūrio į versijų konfliktų sprendimą. Šis faktas vis dar mus trikdo taisant klaidas kaip paramos dalį, todėl nusprendėme apsvarstyti alternatyvias galimybes.
Diskusijos metu buvo suformuoti šie reikalavimai migracijos valdymo sistemai:
- Įvairių DBVS palaikymas. Reikalingos MS SQL Server, PostgreSQL, Oracle, bet galima naudoti ir kitas
- Darbas su ORM. Iš pradžių buvo planuota naudoti EF Core, tačiau projektavimo etape buvome pasirengę apsvarstyti ir kitus ORM.
- Automatinis migracijų generavimas. Atsižvelgdamas į Code First kūrimą, norėčiau išvengti būtinybės „rašyti ranka“ perkėlimų
- Versijų konfliktai. Paskirstytoje kūrimo aplinkoje, kai susijungia, EF Core gali nukentėti nuo konfliktų. Tai tampa rimta problema, nes skirtingas programos dalis kuria skirtingi kūrėjai, todėl kiekvienai turite skirti daug laiko.
- Išplėstinė dokumentacija ir palaikymas. Čia, mums atrodo, jokio paaiškinimo nereikia
- Laisvas. Kriterijus yra sąlyginis, nes sistemos nėra labai brangios ar brangios, bet idealios patogumui, mes taip pat buvome pasirengę apsvarstyti
Atlikus nedidelį tyrimą, buvo rasti ir priimtini apsvarstyti šie variantai:
- EF pagrindinės migracijos
- DBup
- Apvalus namasE
- ThinkingHome.Migrator
- Sklandus migratorius
O dabar šiek tiek detaliau
Natūralu, kad tai buvo pirmasis ir pagrindinis pasirinkimas. Natūralus instrumentas, kuris veikia iš dėžutės, nesivaržant su tamburinu. Didelis kiekis dokumentacijos, oficialus ir ne toks, paprastumas ir t.t. Tačiau skundai dėl klasikinio EF taip pat yra gana svarbūs EF Core.
Taigi išryškinami EF Core pranašumai:
- „Microsoft“ palaikymas, dokumentacija, įskaitant rusų kalba, didžiulė bendruomenė
- Automatinis perkėlimų generavimas pagal CodeFirst
- Palyginti su EF 6, EF Core nebesaugo momentinės duomenų bazės nuotraukos. Dirbant su EF Core programoje Code First, nebereikia diegti duomenų bazės
- Kadangi šokame nuo Code First, galima atlikti vieną migraciją į visus reikiamus duomenų prieigos teikėjus
- Kalbant apie tiekėjus, palaikomas PostgreSQL, palaikomas Oracle ir tt ir tt ir net MS SQL Server
Ir taip pat trūkumai:
- Konfliktų sprendimas išliko tame pačiame lygyje. Būtina sekti migracijas ir atnaujinti duomenų bazės momentines nuotraukas
- Priklausomybė nuo modelių, pagal kuriuos generuojamos migracijos
DbUp
„DbUp“ yra „NuGet“ įdiegta .NET biblioteka, kuri padeda perkelti SQL serverio pakeitimus. Ji seka, kurie pakeitimų scenarijai jau buvo įvykdyti, ir paleidžia tuos, kurie būtini duomenų bazei atnaujinti. Biblioteka išaugo iš atvirojo kodo tinklaraščių variklio projekto ASP.NET ir egzistuoja pagal MIT licenciją, o kodas yra GitHub. Perkėlimai aprašomi naudojant T-SQL.
Kokie privalumai:
- Daugelio DBVS (MS SQL Server, PstgreSQL, MySQL) palaikymas
- Kadangi scenarijai parašyti T-SQL, jie atrodo gana paprasti
- Konfliktai taip pat sprendžiami naudojant SQL
Ir minusai:
- Dėl įvairių palaikomų DBVS „Oracle“ nėra viena iš jų
- Nesąveikauja su ORM
- T-SQL scenarijų rašymas ranka nėra tai, ko mes siekėme
- Dokumentacija ir bendruomenė yra tokia, nors kalbant apie SQL scenarijų rašymą, jie gali būti nereikalingi.
Apvalus namasE
Šis perkėlimo valdymo įrankis, platinamas pagal Apache 2.0 licenciją, kaip ir ankstesnis, veikia T-SQL perkėlimo variklyje. Matyt, kūrėjai pirmenybę teikė techninių problemų, susijusių su DBVS palaikymu, sprendimui, o ne patogiam kūrimo procesui.
Argumentai "už":
- Palaiko reikiamą DBVS (įskaitant „Oracle“)
Trūkumai:
- „Oracle“ (kaip ir „Access“, kuri mums nėra svarbi) nepalaikoma .NET Core, tik .NET Full Framework.
- Neveikia su ORM
- Yra dar mažiau dokumentų nei ankstesniame įrankyje
- Vėlgi – migracijos rašomos scenarijais
ThinkingHome.Migrator
Versijų duomenų bazės schemos perkėlimo į .NET Core platformą įrankis, platinamas pagal MIT licenciją. .
Argumentai "už":
- Sukurta .NET Core
- Įdiegė išsišakojusią migracijų seką
- Įdiegtas migracijos registravimas
Trūkumai:
- Paskutinį kartą atnaujinta prieš metus. Matyt, projektas nepalaikomas
- „Oracle“ nepalaiko (straipsnyje teigiama, kad taip yra dėl to, kad .NET Core nėra stabilaus diegimo, bet tai yra prieš metus)
- Nėra automatinio perkėlimo generavimo
Apskritai projektas atrodo daug žadantis, ypač jei jis vystytųsi, tačiau sprendimą reikėjo priimti čia ir dabar.
Sklandus migratorius
Populiariausias migracijos įrankis su didele gerbėjų armija. Platinama pagal Apache 2.0 licenciją. Kaip nurodyta aprašyme, tai yra .NET perkėlimo sistema, panaši į Ruby on Rails Migrations. Duomenų bazės schemos pakeitimai aprašyti C# klasėse.
Čia yra privalumų:
- Reikalingų DBVS palaikymas
- .NET Core palaikymas
- Didelė išvystyta bendruomenė
- Konfliktai tarp migracijų sprendžiami nuosekliai – nurodoma perkėlimų vykdymo tvarka. Be to, jei konfliktas kyla dėl vieno objekto, sujungiant kodą, jis išsprendžiamas taip pat kaip ir likusioje kodo dalyje
- Yra profilių, kurie vykdomi po sėkmingo perkėlimo. Ir jie gali atlikti aptarnavimo funkcijas.Paskutinis atnaujinimas buvo prieš mėnesį, tai yra projektas gyvas
Kalbant apie minusus, jie yra:
- Nėra automatinio perkėlimo generavimo
- Nėra ryšio su EF modeliais
- Nėra duomenų bazės momentinių vaizdų
Koks buvo mūsų pasirinkimas?
Aršios diskusijos sukosi apie du parametrus – automatinį migracijų generavimą ir protingą konfliktų sprendimą. Kiti veiksniai buvo daug mažiau bauginantys. Dėl to, remdamasi diskusijos rezultatais, komanda nusprendė naujame projekte naudoti „Fluent Migrator“. Nes konfliktų sprendimas ateityje atneš daug daugiau naudos.
išvados
Žinoma, tobulų įrankių nėra. Taigi, norėdami pasirinkti, turėjome teikti pirmenybę savo „norams“. Tačiau kitoms komandoms ir kitoms užduotims lemiami gali būti kiti veiksniai. Tikimės, kad šis straipsnis padės jums pasirinkti.
Šaltinis: www.habr.com