Fergeliking en seleksje fan gegevensmigraasjesystemen
It gegevensmodel hat de neiging om te feroarjen tidens it ûntwikkelingsproses, en op in stuit komt it net mear oerien mei de databank. Fansels kin de databank wiske wurde, en dan sil de ORM in nije ferzje meitsje dy't oerienkomt mei it model, mar dizze proseduere sil liede ta it ferlies fan besteande gegevens. Sa is de funksje fan it migraasjesysteem om te soargjen dat it, as gefolch fan in skemawiziging, syngronisearre wurdt mei it gegevensmodel yn 'e applikaasje sûnder besteande gegevens te ferliezen.
Yn dit artikel wolle wy graach sjen nei ferskate ark foar it behearen fan databasemigraasjes. Wy hoopje dat dizze resinsje nuttich sil wêze foar ûntwikkelders dy't te krijen hawwe mei in ferlykbere kar.
Objective
Us bedriuw ûntwikkelet op it stuit aktyf de folgjende generaasje produkt - Docs Security Suite (DSS). It tsjinner diel is skreaun yn .Net Core, en Entity Framework Core wurdt brûkt as de DBMS. By it ûntwerpen fan in applikaasje brûke wy de Code First-oanpak.
It applikaasjedomeinmodel wurdt makke troch ferskate ûntwikkelders tagelyk - elk is ferantwurdlik foar har eigen logyske diel fan it systeem.
De foarige generaasje fan DSS brûkte de klassike Entity Framework Migrations (EF 6) as it migraasjebehearsysteem. Guon klachten binne der lykwols op sammele, de wichtichste is dat EF in sûne oanpak mist foar it oplossen fan ferzjekonflikten. Dit feit fersteurt ús noch by it reparearjen fan bugs as ûnderdiel fan stipe, dus besleaten wy alternative opsjes te beskôgjen.
As gefolch fan 'e diskusje waarden de folgjende easken foar it migraasjebehearsysteem foarme:
- Stipe foar ferskate DBMS's. MS SQL Server, PostgreSQL, Oracle binne ferplicht, mar it is mooglik mooglik om oaren te brûken
- Wurkje mei ORM. Yn it earstoan wie it pland om EF Core te brûken, mar yn it ûntwerpstadium wiene wy ree om oare ORM's te beskôgjen
- Auto-generaasje fan migraasjes. Mei it rekkenjen fan 'e ûntwikkeling fan Code First, soe ik de needsaak om migraasjes "mei de hân te skriuwen" foarkomme
- Ferzje konflikten. Yn in ferspraat ûntwikkelingsomjouwing, by it fusearjen, kin EF Core lije fan konflikten. Dit wurdt in wichtich probleem om't ferskate dielen fan 'e applikaasje wurde makke troch ferskate ûntwikkelders, dus jo moatte in protte tiid besteegje oan elk
- Avansearre dokumintaasje en stipe. Hjir is, liket ús, gjin taljochting nedich
- Frij. It kritearium is betingst, om't systemen net heul djoer of djoer binne, mar ideaal yn gemak, wiene wy ek ree om te beskôgjen
As resultaat fan in bytsje ûndersyk waarden de folgjende opsjes fûn en winsklik fûn foar konsideraasje:
- EF Core Migrations
- DBup
- Rûnhûs E
- ThinkingHome.Migrator
- Fluent Migrator
En no in bytsje mear detail
Fansels wie dit de earste en wichtichste opsje om te kiezen. In lânseigen ynstrumint dat út 'e doaze wurket sûnder wat mei in tamboeryn te rommeljen. In grutte hoemannichte dokumintaasje, offisjele en net sa, ienfâld, ensfh. De klachten makke oer klassike EF binne lykwols ek frij relevant foar EF Core.
Sa wurde de foardielen foar EF Core markearre:
- Microsoft stipe, dokumintaasje, ynklusyf yn it Russysk, enoarme mienskip
- Auto-generaasje fan migraasjes basearre op CodeFirst
- Yn ferliking mei EF 6 bewarret EF Core net langer in momintopname fan 'e databank. As jo wurkje mei EF Core yn Code First, is it net langer nedich om in databank yn te setten
- Sûnt wy dûnsje fan Code First, is it mooglik om ien migraasje út te fieren nei alle fereaske providers foar gegevenstagong
- Oangeande providers, PostgreSQL wurdt stipe, Oracle wurdt stipe, ensfh., ensfh., En sels MS SQL Server
En ek de neidielen:
- Konfliktresolúsje bleau op itselde nivo. It is needsaaklik om migraasjes te foltôgjen en databank-snapshots te aktualisearjen
- Ofhinklikens fan 'e modellen wêrop de migraasjes wurde generearre
DbUp
DbUp is in .NET-bibleteek dy't ynstalleare is troch NuGet en helpt om feroaringen nei SQL Server te drukken. It hâldt by hokker wizigingsskripts al útfierd binne en rint dejingen dy't nedich binne om de databank te aktualisearjen. De bibleteek groeide út in projekt foar in iepen boarne bloggingmotor op ASP.NET en bestiet ûnder in MIT-lisinsje, en de koade is op GitHub. Migraasjes wurde beskreaun mei T-SQL.
Wat binne de foardielen:
- Stipe foar in grut oantal DBMS (MS SQL Server, PstgreSQL, MySQL)
- Sûnt de skripts binne skreaun yn T-SQL, sjogge se frij ienfâldich
- Konflikten wurde ek oplost mei SQL
En de neidielen:
- Mei al it ferskaat oan stipe DBMS's is Oracle net ien fan har
- Net ynteraksje mei ORM
- T-SQL-skripts mei de hân skriuwe is net wat wy fan doel wiene
- De dokumintaasje en mienskip binne sa-sa, hoewol yn termen fan it skriuwen fan SQL-skripts se miskien net nedich wêze.
Rûnhûs E
Dit ark foar migraasjebehear, ferspraat ûnder de Apache 2.0-lisinsje, lykas de foarige, rint op de T-SQL-migraasjemotor. Blykber hawwe de ûntwikkelders prioriteit foar it oplossen fan technyske problemen oangeande DBMS-stipe, ynstee fan it meitsjen fan in noflik ûntwikkelingsproses.
Pros:
- Unterstützt de nedige DBMS (ynklusyf Oracle)
Cons:
- Oracle (lykas Access, wat foar ús irrelevant is) wurdt net stipe op .NET Core, allinich op .NET Full Framework
- Wurket net mei ORM
- D'r is noch minder dokumintaasje as it foarige ark
- Nochris - migraasjes wurde skreaun troch skripts
ThinkingHome.Migrator
In ark foar ferzjesearre databankskemamigraasje nei it .NET Core-platfoarm, ferspraat ûnder de MIT-lisinsje. .
Pros:
- Ûntwurpen foar .NET Core
- Implementearre in fertakkende folchoarder fan migraasjes
- Implementearre migraasje logging
Cons:
- Lêst bywurke in jier lyn. Nei alle gedachten wurdt it projekt net stipe
- Net stipe troch Oracle (it artikel stelt dat dit komt troch it ûntbrekken fan in stabile ymplemintaasje foar .NET Core - mar dit is in jier lyn)
- Gjin automatyske generaasje fan migraasjes
Oer it algemien liket it projekt kânsryk, benammen as it him ûntwikkelje soe, mar wy moasten hjir en no in beslút nimme.
Fluent Migrator
It populêrste migraasje-ark mei in grut leger fan fans. Ferspraat ûnder de Apache 2.0-lisinsje. Lykas oanjûn yn 'e beskriuwing, is it in migraasjekader foar .NET, fergelykber mei Ruby on Rails Migrations. Feroarings oan de databank skema wurde beskreaun yn C # klassen.
D'r binne foardielen hjir:
- Stipe foar fereaske DBMS
- .NET Core stipe
- Grutte ûntwikkele mienskip
- Konflikten tusken migraasjes wurde sequentially oplost - de folchoarder fan útfiering fan migraasjes wurdt oantsjutte. Derneist, as in konflikt ûntstiet om ien entiteit, wurdt it by it gearfoegjen fan de koade oplost op deselde manier as yn 'e rest fan' e koade
- D'r binne profilen dy't wurde útfierd nei in suksesfolle migraasje. En se kinne tsjinstfunksjes drage. De lêste update wie in moanne lyn, dat is, it projekt libbet
Wat de minussen oanbelanget, hjir binne se:
- Gjin automatyske generaasje fan migraasjes
- Gjin ferbining mei EF-modellen
- Gjin databank momintopnamen
Wat wie ús kar?
De ferhitte debatten draaiden om twa parameters - automatyske generaasje fan migraasjes en ferstannige oplossing fan konflikten. Oare faktoaren wiene folle minder skriklik. As gefolch, basearre op de resultaten fan 'e diskusje, besleat it team Fluent Migrator te brûken yn it nije projekt. Want it oplossen fan konflikten yn 'e takomst sil folle mear foardielen bringe.
befinings
Fansels binne d'r gjin perfekte ark. Dat wy moasten foarrang jaan oan ús "wollen" om in kar te meitsjen. Foar oare teams en oare taken kinne oare faktoaren lykwols beslissend wêze. Wy hoopje dat dit artikel jo sil helpe om in kar te meitsjen.
Boarne: www.habr.com