Krahasimi dhe zgjedhja e sistemeve të migrimit të të dhënave
Modeli i të dhënave gjatë procesit të zhvillimit ka tendencën të ndryshojë, dhe në një moment ai nuk përputhet më me bazën e të dhënave. Sigurisht, baza e të dhënave mund të fshihet, dhe pastaj ORM do të krijojë një version të ri, i cili do të korrespondonte me modelin, por një procedurë e tillë do të çonte në humbjen e të dhënave ekzistuese. Pra, funksioni i sistemit të migrimit është që, si rezultat i ndryshimeve të skemës, ta sinkronizojë atë me modelin e të dhënave në aplikacion pa humbur të dhënat ekzistuese.
Në këtë artikull, dëshirojmë të shqyrtojmë mjetet e ndryshme për menaxhimin e migrimeve të bazave të të dhënave. Shpresojmë që ky përmbledhje të jetë e dobishme për zhvilluesit që përballen me një zgjedhje të tillë.
Detyra
NĂ« kompaninĂ« tonĂ« tani po zhvillohet aktivisht gjenerata e ardhshme e produktit â Docs Security Suite (DSS). Pjesa server po shkruhet nĂ« .Net Core, dhe si DB pĂ«rdoret Entity Framework Core. GjatĂ« projektimit tĂ« aplikacionit, ne pĂ«rdorim qasjen Code First.
Modeli dominal i aplikacionit krijohet nga disa zhvillues nĂ« tĂ« njĂ«jtĂ«n kohĂ« â secili Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r pjesĂ«n logjike tĂ« sistemit.
Në gjeneratën e kaluar të DSS, sistemi i menaxhimit të migrimeve përdorte klasiken Entity Framework Migrations (EF 6). Megjithatë, për të është ngritur disa pretendime, kryesore prej të cilave ishte se në EF mungonte një qasje e arsyeshme për zgjidhjen e konflikteve të versioneve. Ky fakt na shqetëson ende gjatë rregullimeve të defekteve në kuadër të mbështetjes, prandaj u mor vendim të shqyrtohen mundësi alternative.
Si rezultat i diskutimeve, u formuluan këto kërkesa për sistemin e menaxhimit të migrimeve:
- Mbështetje për sisteme të ndryshme DB. Përveç MS SQL Server, PostgreSQL, Oracle, por potencialisht është e mundur të përdoren edhe të tjera.
- Puna me ORM. Fillimisht është parashikuar përdorimi i EF Core, megjithatë në fazën e projektimit ishin të gatshëm të shqyrtonin edhe ORM të tjera.
- Autogenerimi i migrimeve. Duke marrë parasysh zhvillimin Code First, dëshirohej të shmangej nevoja për të "shkruar me dorë" migrimet.
- Konfliktet e versioneve. Në kushte zhvillimi të shpërndarë, gjatë bashkimit, EF Core mund të bjerë për shkak të konflikteve. Kjo bëhet një problem i rëndësishëm, pasi pjesë të ndryshme të aplikacionit krijohen nga zhvillues të ndryshëm, kështu që duhet të shpenzohet shumë kohë për secilin.
- Dokumentacion dhe mbështetje e përparuar. Këtu, na duket se sqarimet nuk janë të nevojshme
- Falësia. Kritereja është relative, sepse nuk jemi përjashtuar nga bisedat rreth sistemeve jo shumë të shtrenjta ose të shtrenjta, por perfekte në komoditet
Si rezultat i një studimi të vogël, janë gjetur dhe pranuar për t'u shqyrtuar variantet e mëposhtme:
- EF Core Migrations
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
Tani pak më në detaje
Natyrisht, ky ishte opsioni i parë dhe kryesor për zgjedhje. Një mjet natyror, që funksionon nga kutia pa ndonjë kërkesë të veçantë. Një sasi e madhe dokumentacioni, si zyrtar ashtu edhe joaq zyrtar, thjeshtësia etj. Sidoqoftë, ankesat që iu bëhen klasikes EF janë gjithashtu të vlefshme për EF Core.
Pra, për EF Core janë identifikuar avantazhet:
- Mbështetje nga Microsoft, dokumentacion, duke përfshirë në rusisht, një komunitet të madh
- Autogjenerimi i migracioneve në bazë të CodeFirst
- Në krahasim me EF 6, EF Core tani nuk ruan një snapshot të DB-së. Kur punoni me EF Core në Code First tani nuk është e nevojshme të zhvilloni bazën e të dhënave
- Duke pasur parasysh se luajmĂ« nga Code First â ka mundĂ«sinĂ« pĂ«r tĂ« menaxhuar njĂ« migracion pĂ«r tĂ« gjitha ofruesit e nevojshĂ«m tĂ« qasjes nĂ« tĂ« dhĂ«na
- Sa i pĂ«rket ofruesve â mbĂ«shtetet si PostgreSQL, ashtu edhe Oracle, etj., dhe madje â MS SQL Server đ
Dhe gjithashtu disavantazhet:
- Zgjidhja e konflikteve ka mbetur në të njëjtin nivel. Nevojitet ndërtimi i një rendi të migracioneve dhe përditësimi i snapshot-eve të DB-së
- Varësia nga modelet, mbi të cilat janë gjeneruar migracionet
DbUp
DbUp është një bibliotekë në .NET që instalon NuGet dhe ndihmon në vendosjen e ndryshimeve në SQL Server. Ajo ndjek se cilat skripte ndryshimi janë përmbushur tashmë dhe fillon ato që janë të nevojshme për përditësimin e DB-së. Biblioteka erdhi nga një projekt i motorit të blogeve të hapura në ASP.NET dhe ekziston nën licencën MIT, dhe kodi është në GitHub. Migracionet përshkruhen përmes T-SQL.
Cilat janë këtu avantazhet:
- Mbështetje për një numër të madh të DBMS-ve (MS SQL Server, PstgreSQL, MySQL)
- Duke qenë se skriptet shkruhen në T-SQL, ato duken mjaft të thjeshta
- Konfliktet gjithashtu zgjidhen përmes SQL
Dhe disavantazhet:
- Me gjithë larminë e DBMS-ve që mbështeten, Oracle nuk është në mesin e tyre
- Nuk bashkëvepron me ORM
- Shkrimi i skripteve nĂ« T-SQL "me dorĂ«" â nuk Ă«shtĂ« ajo pĂ«r tĂ« cilĂ«n po synonim
- Dokumentacioni dhe komuniteti janë të mesëm, megjithatë gjatë shkrimit të skripteve SQL ata ndoshta nuk janë të nevojshëm.
RoundhousE
Ky mjet menaxhimi i migrimeve, i shpërndarë nën licencën Apache 2.0, ashtu si dhe paraardhësi i tij, funksionon mbi motorin e migrimeve T-SQL. Nga ajo që duket, zhvilluesit e kanë vendosur përparësi në zgjidhjen e problemeve teknike në lidhje me mbështetje të bazave të të dhënave, në vend se të krijojnë një proces zhvillimi komod.
Avantazhet:
- Mbështet të nevojshmet e bazave të të dhënave (përfshirë Oracle)
Disavantazhet:
- Oracle (si dhe Access-i që s'ka rëndësi për ne) nuk mbështetet në .NET Core, vetëm në .NET Full Framework
- Nuk funksionon me ORM
- Dokumentacioni është edhe më i pakët se ai i mjetit të mëparshëm
- Edhe njĂ« herĂ« â migrimet shkruhen me skripte
ThinkingHome.Migrator
Një mjet për migrimin versionuar të skemave të bazës së të dhënave për platformën .NET Core, i shpërndarë nën licencën MIT. .
Avantazhet:
- E projektuar për .NET Core
- Eshte realizuar një sekuencë e degëzuar e migrimeve
- Ka realizuar regjistrimin e migrimeve
Disavantazhet:
- PĂ«rditĂ«simi i fundit â njĂ« vit mĂ« parĂ«. Nga duket, projekti nuk mbĂ«shtetet mĂ«
- Nuk mbĂ«shtetet Oracle (nĂ« artikull Ă«shtĂ« deklaruar se kjo Ă«shtĂ« pĂ«r shkak tĂ« mungesĂ«s sĂ« njĂ« realizimi stabil pĂ«r .NET Core â por kjo Ă«shtĂ« njĂ« vit mĂ« parĂ«)
- Mungon autogjenerimi i migrimeve
Në përgjithësi, projekti duket premtues, veçanërisht nëse do të kishte vazhduar, por na duhej të merrnim një vendim këtu dhe tani.
Fluent Migrator
Mjeti më i njohur për migrimet, që ka një ushtri të madhe adhuruesish. Shpërndahet nën licencën Apache 2.0. Siç është shënuar në përshkrim, është një platformë migrimi për .NET, e ngjashme me Migruimet e Ruby on Rails. Ndryshimet në skemën e DB përshkruhen në klasa në C#.
Këtu ka disa përparësi:
- Mbështetje për të nevojshmet e bazave të të dhënave
- Mbështetje për .NET Core
- Një komunitet i madh dhe i zhvilluar
- Konfliktet e migrimeve zgjidhen nĂ« mĂ«nyrĂ« tĂ« njĂ«pasnjĂ«shme â migrimet kanĂ« rendin e ekzekutimit. Gjithashtu, nĂ«se ndodh njĂ« konflikt rreth njĂ« subjekti, gjatĂ« bashkimit tĂ« kodit, zgjidhja bĂ«het njĂ«soj si nĂ« pjesĂ«n tjetĂ«r tĂ« kodit
- Ka profile që ekzekutohet pas përfundimit të suksesshëm të migrimit. Dhe mund të kenë funksione shërbimi. Përditësimi i fundit ishte një muaj më parë, pra projekti është aktiv.
Sa për disavantazhet, këtu ka:
- Mungon autogjenerimi i migrimeve
- Mungon lidhja me modelet EF
- Nuk ka kopje të bazës së të dhënave
Cili ishte përzgjedhja jonë?
Diskutimet mĂ« tĂ« nxehta u zhvilluan rreth dy parametrave â gjenerimi automatik i migrimeve dhe njĂ« zgjidhje e arsyeshme pĂ«r zgjidhjen e konflikteve. FaktorĂ«t e tjerĂ« ishin shumĂ« mĂ« pak tĂ« frikshĂ«m. Si rezultat, ekipi vendosi tĂ« pĂ«rdorĂ« Fluent Migrator nĂ« projektin e ri. Menaxhimi i konflikteve nĂ« perspektivĂ« do tĂ« sjellĂ« shumĂ« mĂ« tepĂ«r pĂ«rfitime.
PĂ«rfundimet
Sigurisht, nuk ekzistojnë mjete ideale. Po ashtu, na duhej të rendisnin prioritetet në dëshirat tona. Sidoqoftë, për ekipe të tjera dhe për detyra të tjera, faktorë të ndryshëm mund të jenë vendimtarë. Shpresojmë që ky artikull do t'ju ndihmojë të bëni zgjedhjen tuaj.
Burimi: habr.com
