Primerjava in izbira sistemov za migracijo podatkov
Podatkovni model se med razvojnim procesom rad spreminja in na neki točki ne ustreza več bazi podatkov. Seveda je bazo mogoče izbrisati in nato bo ORM ustvaril novo različico, ki bo ustrezala modelu, vendar bo ta postopek povzročil izgubo obstoječih podatkov. Tako je funkcija migracijskega sistema zagotoviti, da se zaradi spremembe sheme sinhronizira s podatkovnim modelom v aplikaciji, ne da bi pri tem izgubil obstoječe podatke.
V tem članku bi radi pogledali različna orodja za upravljanje selitev baze podatkov. Upamo, da bo ta pregled koristen za razvijalce, ki se soočajo s podobno izbiro.
Naloga
Naše podjetje trenutno aktivno razvija naslednjo generacijo produkta – Docs Security Suite (DSS). Strežniški del je napisan v .Net Core, Entity Framework Core pa se uporablja kot DBMS. Pri oblikovanju aplikacije uporabljamo pristop Code First.
Model aplikacijske domene ustvarja več razvijalcev hkrati – vsak je odgovoren za svoj logični del sistema.
Prejšnja generacija DSS je kot sistem za upravljanje migracij uporabljala klasične Entity Framework Migrations (EF 6). Vendar se je zoper njega nabralo nekaj pritožb, glavna med njimi je, da EF nima razumnega pristopa k reševanju konfliktov različic. To dejstvo nas še vedno moti pri odpravljanju napak v okviru podpore, zato smo se odločili razmisliti o alternativnih možnostih.
Kot rezultat razprave so se oblikovale naslednje zahteve za sistem upravljanja migracij:
- Podpora za različne DBMS. Potrebni so MS SQL Server, PostgreSQL, Oracle, možno pa je uporabiti tudi druge
- Delo z ORM. Sprva je bila načrtovana uporaba EF Core, vendar smo bili v fazi načrtovanja pripravljeni razmisliti o drugih ORM
- Samodejno ustvarjanje migracij. Ob upoštevanju razvoja Code First bi se rad izognil potrebi po "ročno pisanih" migracijah
- Konflikti različic. V porazdeljenem razvojnem okolju lahko pri združevanju EF Core trpi zaradi konfliktov. To postane velik problem, ker različne dele aplikacije ustvarijo različni razvijalci, zato morate za vsakega porabiti veliko časa.
- Napredna dokumentacija in podpora. Tukaj se nam zdi, da razlaga ni potrebna
- Prost. Merilo je pogojeno, saj sistemi niso zelo dragi ali dragi, a idealni v priročnosti, smo bili pripravljeni upoštevati tudi
Kot rezultat majhne raziskave so bile ugotovljene naslednje možnosti, ki so bile zaželene za obravnavo:
- EF Core Migrations
- DBup
- Okrogla hišaE
- ThinkingHome.Migrator
- Fluent Migrator
In zdaj malo več podrobnosti
Seveda je bila to prva in glavna možnost izbire. Domači inštrument, ki deluje takoj, brez kakršnih koli posegov po tamburini. Velika količina dokumentacije, uradne in ne tako, preprostost itd. Vendar pa so pritožbe glede klasičnega EF zelo pomembne tudi za EF Core.
Tako so poudarjene prednosti za EF Core:
- Microsoftova podpora, dokumentacija, tudi v ruščini, velika skupnost
- Samodejno ustvarjanje migracij na osnovi CodeFirst
- V primerjavi z EF 6 EF Core ne shranjuje več posnetka baze podatkov. Ko delate z EF Core v Code First, ni več treba uvesti baze podatkov
- Ker plešemo od Code First, je mogoče izvesti eno selitev na vse zahtevane ponudnike dostopa do podatkov
- Glede ponudnikov je podprt PostgreSQL, podprt je Oracle itd. itd. in celo MS SQL Server
In tudi slabosti:
- Reševanje konfliktov je ostalo na enaki ravni. Potrebno je zaporedje selitev in posodobitev posnetkov baze podatkov
- Odvisnost od modelov, na katerih so generirane migracije
DbUp
DbUp je knjižnica .NET, ki jo namesti NuGet in pomaga potisniti spremembe v SQL Server. Spremlja, kateri skripti sprememb so že bili izvedeni, in izvaja tiste, ki so potrebni za posodobitev baze podatkov. Knjižnica je zrasla iz projekta za odprtokodni motor za bloganje na ASP.NET in obstaja pod licenco MIT, koda pa je na GitHubu. Migracije so opisane z uporabo T-SQL.
Kakšne so prednosti:
- Podpora za veliko število DBMS (MS SQL Server, PstgreSQL, MySQL)
- Ker so skripte napisane v T-SQL, so videti precej preproste
- Konflikti se rešujejo tudi z uporabo SQL
In slabosti:
- Ob vsej raznolikosti podprtih DBMS-jev Oracle ni eden izmed njih
- Ne deluje z ORM
- Ročno pisanje skriptov T-SQL ni tisto, kar smo si prizadevali
- Dokumentacija in skupnost sta tako-tako, čeprav v smislu pisanja skriptov SQL morda nista potrebna.
Okrogla hišaE
To orodje za upravljanje selitev, distribuirano pod licenco Apache 2.0, tako kot prejšnje deluje na mehanizmu za selitev T-SQL. Očitno so razvijalci dali prednost reševanju tehničnih težav v zvezi s podporo za DBMS, namesto da bi ustvarili udoben razvojni proces.
Profesionalci:
- Podpira potrebne DBMS (vključno z Oracle)
Cons:
- Oracle (kot tudi Access, ki je za nas nepomemben) ni podprt v .NET Core, samo v .NET Full Framework
- Ne deluje z ORM
- Dokumentacije je še manj kot prejšnje orodje
- Še enkrat – migracije pišejo skripti
ThinkingHome.Migrator
Orodje za selitev sheme baz podatkov z različicami na platformo .NET Core, ki se distribuira pod licenco MIT. .
Profesionalci:
- Zasnovan za .NET Core
- Implementirano razvejano zaporedje selitev
- Implementirano beleženje selitev
Cons:
- Nazadnje posodobljeno pred enim letom. Očitno projekt ni podprt
- Oracle ne podpira (članek navaja, da je to posledica pomanjkanja stabilne implementacije za .NET Core – vendar je to pred letom dni)
- Brez samodejnega ustvarjanja selitev
Na splošno je projekt videti obetaven, še posebej, če bi se razvijal, vendar smo se morali odločiti tukaj in zdaj.
Fluent Migrator
Najbolj priljubljeno orodje za selitev z veliko vojsko oboževalcev. Distribuirano pod licenco Apache 2.0. Kot je navedeno v opisu, gre za migracijsko ogrodje za .NET, podobno Ruby on Rails Migrations. Spremembe sheme baze podatkov so opisane v razredih C#.
Tukaj so prednosti:
- Podpora za zahtevane DBMS
- Podpora za .NET Core
- Velika razvita skupnost
- Konflikti med selitvami se rešujejo zaporedno – določen je vrstni red izvajanja selitev. Poleg tega, če pride do konflikta okoli ene entitete, se pri združevanju kode le-ta razreši na enak način kot v preostalem delu kode
- Obstajajo profili, ki se izvedejo po uspešni selitvi. In lahko opravljajo storitvene funkcije. Zadnja posodobitev je bila pred mesecem dni, torej je projekt živ
Kar se tiče minusov, so tukaj:
- Brez samodejnega ustvarjanja selitev
- Ni povezave z modeli EF
- Ni posnetkov baze podatkov
Kakšna je bila naša izbira?
Burne razprave so se vrtele okoli dveh parametrov - avtomatskega generiranja migracij in razumnega reševanja konfliktov. Drugi dejavniki so bili veliko manj zastrašujoči. Posledično se je ekipa na podlagi rezultatov razprave odločila, da bo v novem projektu uporabila Fluent Migrator. Ker bo reševanje konfliktov v prihodnosti prineslo veliko več koristi.
Ugotovitve
Seveda popolnih orodij ni. Zato smo morali dati prednost svojim »željam«, da smo lahko izbrali. Za druge ekipe in druge naloge pa so lahko odločilni drugi dejavniki. Upamo, da vam bo ta članek pomagal pri izbiri.
Vir: www.habr.com