Krahasimi dhe zgjedhja e sistemeve të migrimit të të dhënave.
Modeli i të dhënave në procesin e zhvillimit ka vetinë të ndryshojë, dhe në një moment ai ndalon së qenuri në përputhje me bazën e të dhënave. Sigurisht, mund të fshini DB-në, dhe atëherë ORM do të krijojë një version të ri që do të përputhet me modelin, por një procedurë e tillë do të çojë në humbjen e të dhënave ekzistuese. Kështu, funksioni i sistemit të migrimit përfshin sinkronizimin e skemës me modelin e të dhënave në aplikacion pa humbjen e të dhënave ekzistuese.
Në këtë artikull do të shqyrtojmë mjete të ndryshme për menaxhimin e migrimeve të bazave të të dhënave. Shpresojmë që ky përmbledhje do të jetë e dobishme për zhvilluesit që janë përballur me një zgjedhje të tillë.
Detyra
NĂ« kompani po zhvillohet aktivisht gjenerata e ardhshme e produktit â Docs Security Suite (DSS). Pjesa server ndĂ«rtçohet nĂ« .Net Core, dhe si DBMS pĂ«rdoret Entity Framework Core. Kur projektojmĂ« aplikacionin, ne pĂ«rdorim qasjen Code First.
Modeli i domenit tĂ« aplikacionit krijohet nga disa zhvillues nĂ« tĂ« njĂ«jtĂ«n kohĂ« â secili pĂ«rgjigjet pĂ«r pjesĂ«n e tij logjike tĂ« sistemit.
Në brezin e mëparshëm të DSS, sistemi i menaxhimit të migrimeve përdorte klasiken Entity Framework Migrations (EF 6). Megjithatë, ndaj këtij sistemi kishin shpërthyer disa ankesat, më e rëndësishmja prej të cilave ishte se në EF mungonte një qasje e arsyeshme për zgjidhjen e konflikteve të versioneve. Ky fakt vazhdon të na shqetësojë gjatë rregullimit të defekteve në kuadër të mbështetjes, prandaj u mor vendimi për të shqyrtuar opsione alternative.
Si rezultat i diskutimeve, u formuluan kërkesa të mëposhtme për sistemin e menaxhimit të migrimeve:
- Mbështetje për DBM të ndryshme. Domosdoshmërisht MS SQL Server, PostgreSQL, Oracle, por potencialisht mund të përdoren edhe të tjera.
- Puna me ORM. Fillimisht ishte parashikuar përdorimi i EF Core, megjithatë në fazën e projektimit ishim të gatshëm të shqyrtonim edhe ORM të tjera.
- Autogjenerimi i migrimeve. Duke marrë parasysh zhvillimin Code First, do të donim të evitonim nevojën për të "shkruar dorazi" migrimet.
- Konfliktet e versioneve. Në kushte zhvillimi të shpërndarë, gjatë bashkimit, EF Core mund të hasë konflikte. Kjo bëhet një problem i rëndësishëm, pasi pjesë të ndryshme të aplikacionit krijohen nga zhvillues të ndryshëm, prandaj duhet të kalojmë shumë kohë për çdo konflikt.
- Dokumentacion i avancuar dhe mbështetje. Këtu, mendojmë se shpjegimet nuk janë të nevojshme.
- Përfitimi nga falas. Kriteri është i kushtueshëm, pasi sistemet jo shumë të shtrenjta apo shumë të shtrenjta, por ideale në lehtësinë e përdorimit, jemi gjithashtu të gatshëm t'i shqyrtojmë.
Si rezultat i një hulumtimi të vogël, u gjendën dhe u njohën si të dëshiruara për shqyrtim këto mundësi:
- Efekti i Transferimeve EF Core
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
Tani pak më në detaje
Natyrisht, kjo ishte zgjedhja e parë dhe kryesore. Një mjet natyror që funksionon nga kutia pa asnjë komplikim. Një sasi e madhe dokumentacioni, zyrtar dhe jo aq zyrtar, thjeshtësia etj. Sidoqoftë, ankesat që janë ngritur për EF klasik janë gjithashtu aktuale për EF Core.
Pra, për EF Core janë identifikuar avantazhet:
- Mbështetje nga Microsoft, dokumentacion, përfshirë në gjuhën shqipe, një komunitet i jashtëzakonshëm.
- Autogenerimi i migrimeve mbi bazën e CodeFirst
- Krahasuar me EF 6, në EF Core tani nuk ruhet një snapshot i DB. Gjatë punës me EF Core në Code First, tani nuk është e nevojshme të përgatitet një bazë të dhënash.
- Duke filluar nga Code First - ka mundësinë për të mbajtur një migrim për të gjithë ofruesit e nevojshëm të qasjes në të dhëna.
- Për sa i përket ofruesve - përkrahët si PostgreSQL, ashtu edhe Oracle, etj., madje edhe - MS SQL Server :)
Dhe gjithashtu të metat:
- Zgjidhja e konflikteve ka mbetur nĂ« tĂ« njĂ«jtin nivel. ĂshtĂ« e nevojshme tĂ« ndĂ«rtosh njĂ« rend tĂ« migrimeve dhe tĂ« pĂ«rditĂ«sosh snapshot-et e DB.
- Varësia nga modelet mbi të cilat janë gjeneruar migrimet.
DbUp
DbUp është një bibliotekë në .NET, e cila instalohet me NuGet dhe ndihmon në zbatimin e ndryshimeve në SQL Server. Ajo ndjek se cilat skripte ndryshimesh janë ekzekutuar tashmë dhe ekzekuton ato që janë të nevojshme për përditësimin e DB. Biblioteka ka evoluar nga një projekt motori blogesh me burim të hapur në ASP.NET dhe ekziston nën licencën MIT, ndërsa kodi është në GitHub. Migrimet përshkruhën me T-SQL.
Cilat janë këtu përparësitë:
- Përkrahja e një numri të madh të DBMS-ve (MS SQL Server, PostgreSQL, MySQL)
- Duke qenë se skriptet shkruhen në T-SQL, ato duken mjaft të thjeshta.
- Konfliktet gjithashtu zgjidhen përmes SQL
Por disavantazhet:
- Megjithë shumëllojshmërinë e DBMS-ve të mbështetur, Oracle nuk është në mesin e tyre
- Nuk ndërvepron me ORM
- Shkrimi i skriptave nĂ« T-SQL "me dorĂ«" â nuk Ă«shtĂ« ajo nĂ« tĂ« cilĂ«n synonim
- Dokumentimi dhe komuniteti janë disi të dobët, megjithatë në kushte të shkrimit të skripteve SQL ata ndoshta nuk kanë nevojë.
RoundhousE
Ky mjet menaxhimi i migrimeve, që shpërndahet nën licencën Apache 2.0, si dhe i mëparshmi, funksionon në motorin e migrimeve T-SQL. Sipas duket, zhvilluesit kishin si prioritet zgjidhjen e problemeve teknike në mbështetje të DBMS-ve, dhe jo krijimin e një procesi komod zhvillimi.
Avantazhet:
- Mbështet DBMS-të e nevojshme (përfshirë Oracle)
Disavantazhet:
- Oracle (ashtu si Access-i që nuk është aktual për ne) nuk mbështetet në .NET Core, vetëm në .NET Full Framework
- Nuk funksionon me ORM
- Dokumentimi është edhe më pak se ai i mjetit të mëparshëm
- PĂ«rsĂ«ri â migrimet shkruhen me skripte
ThinkingHome.Migrator
Një mjet për migrimin versionuar të skemës së bazës së të dhënave për platformën .NET Core, që shpërndahet nën licencën MIT. .
Avantazhet:
- I dizajnuar për .NET Core
- E zbatueshme një renditje e ndërlikuar migrimesh
- Logimi i migrimeve është realizuar
Disavantazhet:
- PĂ«rditĂ«simi i fundit â para njĂ« viti. Duket se projekti nuk mbĂ«shtetet mĂ«
- Oracle nuk mbĂ«shtetet (artikulli thotĂ« se kjo Ă«shtĂ« pĂ«r shkak tĂ« mungesĂ«s sĂ« njĂ« implementimi tĂ« qĂ«ndrueshĂ«m pĂ«r .NET Core â por kjo erdhi njĂ« vit mĂ« parĂ«)
- Mungon gjenerimi automatik i migrimeve
Në tërësi, projekti duket premtues, veçanërisht nëse do të ishte zhvilluar, por na nevojitej të merrnim një vendim këtu dhe tani.
Fluent Migrator
Instrumenti më i njohur për migrimet, me një bazë të madhe ndjekësish. Shpërndahet nën licencën Apache 2.0. Siç thuhet në përshkrim, është një platformë migrimi për .NET, e ngjashme me Ruby on Rails Migrations. Ndryshimet e skemës së DB përshkruhen në klasa në C#.
Këtu ka përfitime:
- Mbështetje për DBMS të nevojshme
- Mbështetje për .NET Core
- Një komunitet i madh i zhvilluar
- Konkfliktet e migrimeve zgjidhen nĂ« mĂ«nyrĂ« tĂ« vazhdueshme â migrimet kanĂ« rendin e ekzekutimit tĂ« pĂ«rcaktuar. PĂ«r mĂ« tepĂ«r, nĂ«se ndodh njĂ« konflikt rreth njĂ« entiteti tĂ« vetĂ«m, zgjidhja nĂ« pĂ«rpjekjen e kodit bĂ«het ashtu siç Ă«shtĂ« bĂ«rĂ« pĂ«r kodin tjetĂ«r.
- Ka janë profile që realizohen pas përfundimit të suksesshëm të migracionit. Ato mund të kenë funksione shërbimi. Përditësimi i fundit ka qenë para një muaji, do të thotë se projekti është aktive.
Sa i përket disavantazheve, këtu janë:
- Mungon gjenerimi automatik i migrimeve
- Mungon lidhja me modelet EF
- Nuk ka kopi të DB
Cili ishte zgjedhja jonë?
Diskutimet mĂ« tĂ« ashpra u zhvilluan rreth dy parametrave â autogjenerimi i migracioneve dhe njĂ« zgjidhje e arsyeshme pĂ«r konfliktet. FaktorĂ«t e tjerĂ« ishin shumĂ« mĂ« pak shqetĂ«sues. NĂ« pĂ«rfundim, si rezultat i diskutimit, ekipi vendosi tĂ« pĂ«rdorĂ« Fluent Migrator nĂ« projektin e ri. Sepse zgjidhja e konflikteve nĂ« perspektivĂ«n afatgjatĂ« do tĂ« sjellĂ« shumĂ« mĂ« tepĂ«r pĂ«rfitime.
PĂ«rfundimet
Sigurisht, nuk ka mjete perfekte. Edhe ne, për t'u vendosur në zgjedhjen tonë, duhej të vendosnim prioritetet në 'dëshirat' tona. Megjithatë, për ekipet e tjera dhe për detyra të tjera, faktorë të tjerë mund të duken vendimtarë. Shpresojmë që ky artikull të ndihmojë në zgjedhjen tuaj.
Burimi: habr.com
