Krahasimi dhe përzgjedhja e sistemeve të migrimit të të dhënave
Modeli i të dhënave tenton të ndryshojë gjatë procesit të zhvillimit, dhe në një moment ai nuk korrespondon më me bazën e të dhënave. Natyrisht, baza e të dhënave mund të fshihet dhe më pas ORM do të krijojë një version të ri që do të përputhet me modelin, por kjo procedurë do të çojë në humbjen e të dhënave ekzistuese. Kështu, funksioni i sistemit të migrimit është të sigurojë që, si rezultat i një ndryshimi të skemës, ai të sinkronizohet me modelin e të dhënave në aplikacion pa humbur të dhënat ekzistuese.
Në këtë artikull, ne do të dëshironim të shikonim mjete të ndryshme për menaxhimin e migrimeve të bazës së të dhënave. Shpresojmë që ky rishikim të jetë i dobishëm për zhvilluesit që përballen me një zgjedhje të ngjashme.
Detyrë
Kompania jonë aktualisht po zhvillon në mënyrë aktive gjeneratën e ardhshme të produktit - Docs Security Suite (DSS). Pjesa e serverit është shkruar në .Net Core dhe Entity Framework Core përdoret si DBMS. Kur hartojmë një aplikacion, ne përdorim qasjen Code First.
Modeli i domenit të aplikacionit krijohet nga disa zhvillues në të njëjtën kohë - secili është përgjegjës për pjesën e tij logjike të sistemit.
Gjenerata e mëparshme e DSS përdorte Migrimet klasike të Kornizës së Entitetit (EF 6) si sistem të menaxhimit të migracionit. Megjithatë, kundër tij janë grumbulluar disa ankesa, ku kryesorja është se EF-it i mungon një qasje e arsyeshme për zgjidhjen e konflikteve të versioneve. Ky fakt ende na shqetëson kur rregullojmë gabimet si pjesë e mbështetjes, kështu që vendosëm të shqyrtojmë opsionet alternative.
Si rezultat i diskutimit, u formuan kërkesat e mëposhtme për sistemin e menaxhimit të migracionit:
- Mbështetje për DBMS të ndryshme. Kërkohen MS SQL Server, PostgreSQL, Oracle, por është potencialisht e mundur të përdoren të tjerë
- Puna me ORM. Fillimisht, ishte planifikuar të përdorej EF Core, por në fazën e projektimit ne ishim gati të merrnim parasysh ORM të tjera
- Gjenerimi automatik i migrimeve. Duke marrë parasysh zhvillimin e Code First, do të doja të shmangja nevojën për të "shkruar me dorë" migrimet
- Konfliktet e versioneve. Në një mjedis zhvillimi të shpërndarë, kur bashkohet, EF Core mund të vuajë nga konfliktet. Ky bëhet një problem i rëndësishëm sepse pjesë të ndryshme të aplikacionit krijohen nga zhvillues të ndryshëm, kështu që ju duhet të shpenzoni shumë kohë për secilën
- Dokumentacion dhe mbështetje e avancuar. Këtu, na duket, nuk ka nevojë për shpjegim
- Falas. Kriteri është i kushtëzuar, pasi sistemet nuk janë shumë të shtrenjta ose të shtrenjta, por ideale në komoditet, ne ishim gjithashtu të gatshëm të merrnim parasysh
Si rezultat i një kërkimi të vogël, opsionet e mëposhtme u gjetën dhe u gjetën të dëshirueshme për t'u marrë në konsideratë:
- Migrimet thelbësore EF
- DBup
- Shtëpia e rrumbullakëtE
- ThinkingHome.Migrator
- Migrues i rrjedhshëm
Dhe tani pak më shumë detaje
Natyrisht, ky ishte opsioni i parë dhe kryesor për të zgjedhur. Një instrument vendas që funksionon jashtë kutisë pa asnjë pëllëmbë me një dajre. Një sasi e madhe dokumentacioni, zyrtar dhe jo aq, thjeshtësi etj. Sidoqoftë, ankesat e bëra për EF klasik janë gjithashtu mjaft të rëndësishme për EF Core.
Kështu, përparësitë për EF Core theksohen:
- Mbështetja, dokumentacioni i Microsoft, përfshirë në Rusisht, komunitet i madh
- Gjenerimi automatik i migrimeve bazuar në CodeFirst
- Krahasuar me EF 6, EF Core nuk ruan më një fotografi të bazës së të dhënave. Kur punoni me EF Core në Code First, nuk është më e nevojshme të vendosni një bazë të dhënash
- Meqenëse po kërcejmë nga Code First, është e mundur të kryhet një migrim te të gjithë ofruesit e kërkuar të aksesit të të dhënave
- Sa i përket ofruesve, PostgreSQL mbështetet, Oracle mbështetet, etj., etj., madje edhe MS SQL Server
Dhe gjithashtu disavantazhet:
- Zgjidhja e konfliktit mbeti në të njëjtin nivel. Është e nevojshme të renditen migrimet dhe të përditësohen fotografitë e bazës së të dhënave
- Varësia nga modelet mbi të cilat krijohen migrimet
DbUp
DbUp është një bibliotekë .NET që është instaluar nga NuGet dhe ndihmon në shtytjen e ndryshimeve në SQL Server. Mban gjurmët e skripteve të ndryshimeve që janë ekzekutuar tashmë dhe ekzekuton ato që janë të nevojshme për përditësimin e bazës së të dhënave. Biblioteka u ngrit nga një projekt për një motor blogimi me burim të hapur në ASP.NET dhe ekziston nën një licencë MIT, dhe kodi është në GitHub. Migrimet përshkruhen duke përdorur T-SQL.
Cilat janë avantazhet:
- Mbështetje për një numër të madh DBMS (MS SQL Server, PstgreSQL, MySQL)
- Meqenëse skriptet janë shkruar në T-SQL, ato duken mjaft të thjeshta
- Konfliktet zgjidhen gjithashtu duke përdorur SQL
Dhe të këqijat:
- Me gjithë shumëllojshmërinë e DBMS-ve të mbështetura, Oracle nuk është një prej tyre
- Nuk ndërvepron me ORM
- Shkrimi i skripteve T-SQL me dorë nuk është ajo që synonim
- Dokumentacioni dhe komuniteti janë kaq, megjithëse për sa i përket shkrimit të skripteve SQL, ato mund të mos jenë të nevojshme.
Shtëpia e rrumbullakëtE
Ky mjet i menaxhimit të migrimit, i shpërndarë nën licencën Apache 2.0, si ai i mëparshmi, funksionon në motorin e migrimit T-SQL. Me sa duket, zhvilluesit i dhanë përparësi zgjidhjes së problemeve teknike në lidhje me mbështetjen e DBMS, në vend që të krijonin një proces të rehatshëm zhvillimi.
Pro:
- Mbështet DBMS-në e nevojshme (përfshirë Oracle)
Cons:
- Oracle (si dhe Access, që është e parëndësishme për ne) nuk mbështetet në .NET Core, vetëm në .NET Full Framework
- Nuk funksionon me ORM
- Ka edhe më pak dokumentacion se mjeti i mëparshëm
- Përsëri - migrimet shkruhen nga skriptet
ThinkingHome.Migrator
Një mjet për migrimin e skemës së bazës së të dhënave të versionuara në platformën .NET Core, i shpërndarë nën licencën MIT. .
Pro:
- Projektuar për .NET Core
- Zbatoi një sekuencë degëzimi të migrimeve
- Regjistrimi i migracionit i zbatuar
Cons:
- Përditësuar për herë të fundit një vit më parë. Me sa duket projekti nuk mbështetet
- Nuk mbështetet nga Oracle (artikulli thotë se kjo është për shkak të mungesës së një zbatimi të qëndrueshëm për .NET Core - por kjo është një vit më parë)
- Nuk ka gjenerim automatik të migrimeve
Në përgjithësi, projekti duket premtues, veçanërisht nëse do të zhvillohej, por ne duhej të merrnim një vendim këtu dhe tani.
Migrues i rrjedhshëm
Mjeti më i popullarizuar i migrimit me një ushtri të madhe fansash. Shpërndarë nën licencën Apache 2.0. Siç thuhet në përshkrim, është një kornizë migrimi për .NET, e ngjashme me Ruby on Rails Migrations. Ndryshimet në skemën e bazës së të dhënave përshkruhen në klasat C#.
Këtu ka përparësi:
- Mbështetje për DBMS të kërkuara
- Mbështetje .NET Core
- Komunitet i madh i zhvilluar
- Konfliktet ndërmjet migrimeve zgjidhen në mënyrë sekuenciale - specifikohet rendi i ekzekutimit të migrimeve. Përveç kësaj, nëse lind një konflikt rreth një entiteti, kur bashkohet kodi, ai zgjidhet në të njëjtën mënyrë si në pjesën tjetër të kodit
- Ka profile që ekzekutohen pas një migrimi të suksesshëm. Dhe mund të kryejnë funksione shërbimi.Përditësimi i fundit ishte një muaj më parë, domethënë projekti është i gjallë
Sa për minuset, këtu janë ato:
- Nuk ka gjenerim automatik të migrimeve
- Nuk ka lidhje me modelet EF
- Nuk ka fotografi të bazës së të dhënave
Cila ishte zgjedhja jonë?
Debatet e nxehta u rrotulluan rreth dy parametrave - gjenerimi automatik i migrimeve dhe zgjidhja e arsyeshme e konflikteve. Faktorët e tjerë ishin shumë më pak të frikshëm. Si rezultat, bazuar në rezultatet e diskutimit, ekipi vendosi të përdorte Fluent Migrator në projektin e ri. Sepse zgjidhja e konflikteve në të ardhmen do të sjellë shumë më tepër përfitime.
Gjetjet
Sigurisht, nuk ka mjete perfekte. Kështu që ne duhej t'i jepnim përparësi "dëshirave" tona për të bërë një zgjedhje. Megjithatë, për ekipet e tjera dhe detyrat e tjera, faktorë të tjerë mund të jenë vendimtarë. Shpresojmë që ky artikull t'ju ndihmojë të bëni një zgjedhje.
Burimi: www.habr.com