Samanburður og val á gagnaflutningskerfum
Gagnalíkanið hefur tilhneigingu til að breytast í þróunarferlinu og á einhverjum tímapunkti samsvarar það ekki lengur gagnagrunninum. Auðvitað er hægt að eyða gagnagrunninum og þá mun ORM búa til nýja útgáfu sem passar við líkanið, en þetta ferli mun leiða til taps á núverandi gögnum. Þannig er hlutverk flutningskerfisins að tryggja að vegna skemabreytingar sé það samstillt við gagnalíkanið í forritinu án þess að tapa núverandi gögnum.
Í þessari grein viljum við skoða ýmis verkfæri til að stjórna gagnagrunnsflutningum. Við vonum að þessi endurskoðun verði gagnleg fyrir forritara sem standa frammi fyrir svipuðu vali.
Verkefni
Fyrirtækið okkar er sem stendur að þróa næstu kynslóð vöru – Docs Security Suite (DSS). Miðlarahlutinn er skrifaður í .Net Core og Entity Framework Core er notað sem DBMS. Við hönnun forrits notum við Code First nálgunina.
Forritslénslíkanið er búið til af nokkrum forriturum á sama tíma - hver ber ábyrgð á sínum rökrétta hluta kerfisins.
Fyrri kynslóð DSS notaði klassíska Entity Framework Migrations (EF 6) sem flutningsstjórnunarkerfi. Hins vegar hafa nokkrar kvartanir safnast upp gegn því, helsta sú að EF skortir skynsamlega nálgun til að leysa útgáfuárekstra. Þessi staðreynd kemur okkur enn í uppnám þegar við lagfærum villur sem hluta af stuðningi, svo við ákváðum að íhuga aðra valkosti.
Í kjölfar umræðunnar voru settar fram eftirfarandi kröfur fyrir flutningsstjórnunarkerfið:
- Stuðningur við ýmis DBMS. MS SQL Server, PostgreSQL, Oracle eru nauðsynlegar, en hugsanlega er hægt að nota aðra
- Að vinna með ORM. Upphaflega var áætlað að nota EF Core, en á hönnunarstigi vorum við tilbúin að huga að öðrum ORM
- Sjálfvirk myndun fólksflutninga. Að teknu tilliti til þróunar Code First, vil ég forðast þörfina á að „handskrifa“ flutninga
- Útgáfuárekstrar. Í dreifðu þróunarumhverfi, við sameiningu, getur EF Core orðið fyrir átökum. Þetta verður verulegt vandamál vegna þess að mismunandi hlutar forritsins eru búnir til af mismunandi hönnuðum, svo þú þarft að eyða miklum tíma í hvern
- Ítarleg skjöl og stuðningur. Hér sýnist okkur engin þörf á skýringum
- Ókeypis. Viðmiðið er skilyrt, þar sem kerfi eru ekki mjög dýr eða dýr, en tilvalin í hentugleika, vorum við líka tilbúin að íhuga
Sem afleiðing af smá rannsókn fundust eftirfarandi valkostir og þóttu æskilegir til skoðunar:
- EF Core Migrations
- DBup
- RoundhouseE
- ThinkingHome.Migrator
- Fluent Migrator
Og nú aðeins meiri smáatriði
Auðvitað var þetta fyrsti og helsti kosturinn til að velja. Náttúrulegt hljóðfæri sem virkar upp úr kassanum án þess að fikta í bumbúrínu. Mikið magn af skjölum, opinberum og ekki svo, einfaldleiki osfrv. Hins vegar eru kvartanir um klassískt EF einnig mjög viðeigandi fyrir EF Core.
Þannig eru kostir EF Core dregnir fram:
- Stuðningur Microsoft, skjöl, þar á meðal á rússnesku, risastórt samfélag
- Sjálfvirk kynslóð flutninga byggða á CodeFirst
- Í samanburði við EF 6 geymir EF Core ekki lengur skyndimynd af gagnagrunninum. Þegar unnið er með EF Core í Code First er ekki lengur nauðsynlegt að dreifa gagnagrunni
- Þar sem við erum að dansa frá Code First er hægt að framkvæma eina flutning til allra nauðsynlegra gagnaaðgangsveitenda
- Varðandi veitendur, PostgreSQL er stutt, Oracle er stutt osfrv., osfrv., og jafnvel MS SQL Server
Og líka gallarnir:
- Lausn átaka var á sama stigi. Nauðsynlegt er að raða flutningum og uppfæra skyndimyndir gagnagrunns
- Það er háð líkönunum sem flutningarnir eru búnir til
DbUp
DbUp er .NET bókasafn sem er sett upp af NuGet og hjálpar til við að ýta undir breytingar á SQL Server. Það heldur utan um hvaða breytingarforskriftir hafa þegar verið keyrðar og keyrir þau sem nauðsynleg eru til að uppfæra gagnagrunninn. Bókasafnið ólst upp úr verkefni fyrir opinn uppspretta bloggvél á ASP.NET og er til undir MIT leyfi og kóðinn er á GitHub. Flutningum er lýst með T-SQL.
Hverjir eru kostir:
- Stuðningur við mikinn fjölda DBMS (MS SQL Server, PstgreSQL, MySQL)
- Þar sem forskriftirnar eru skrifaðar í T-SQL líta þau frekar einföld út
- Átök eru einnig leyst með SQL
Og gallarnir:
- Með alls kyns studdum DBMS-tækjum er Oracle ekki einn af þeim
- Hefur ekki samskipti við ORM
- Að skrifa T-SQL forskriftir í höndunum er ekki það sem við stefndum að
- Skjölin og samfélagið er svo sem svo, þó að það sé kannski ekki nauðsynlegt hvað varðar ritun SQL forskrifta.
RoundhouseE
Þetta flutningsstjórnunartól, dreift undir Apache 2.0 leyfinu, eins og það fyrra, keyrir á T-SQL flutningsvélinni. Svo virðist sem verktaki hafi forgangsraðað að leysa tæknileg vandamál varðandi DBMS stuðning, frekar en að búa til þægilegt þróunarferli.
Kostir:
- Styður nauðsynlega DBMS (þar á meðal Oracle)
Gallar:
- Oracle (sem og Access, sem er okkur óviðkomandi) er ekki stutt á .NET Core, aðeins á .NET Full Framework
- Virkar ekki með ORM
- Það er jafnvel minna skjöl en fyrra tólið
- Aftur - fólksflutningar eru skrifaðir með skriftum
ThinkingHome.Migrator
Tól til að flytja útgáfa gagnagrunnsskema yfir á .NET Core vettvang, dreift undir MIT leyfinu. .
Kostir:
- Hannað fyrir .NET Core
- Innleiddi greinaröð fólksflutninga
- Innleitt flutningsskráningu
Gallar:
- Síðast uppfært fyrir ári síðan. Svo virðist sem verkefnið sé ekki stutt
- Ekki studd af Oracle (greinin segir að þetta sé vegna skorts á stöðugri útfærslu fyrir .NET Core - en þetta er ár síðan)
- Engin sjálfvirk kynslóð fólksflutninga
Á heildina litið lítur verkefnið góðu út, sérstaklega ef það myndi þróast, en við þurftum að taka ákvörðun hér og nú.
Fluent Migrator
Vinsælasta fólksflutningatækið með stóran her aðdáenda. Dreift undir Apache 2.0 leyfinu. Eins og fram kemur í lýsingunni er það flutningsramma fyrir .NET, svipað og Ruby on Rails Migrations. Breytingum á gagnagrunnsskemanu er lýst í C# flokkum.
Það eru kostir hér:
- Stuðningur við nauðsynlegar DBMS
- .NET Core stuðningur
- Stórt þróað samfélag
- Ágreiningur milli flutninga er leystur í röð – röð flutninga er tilgreind. Að auki, ef ágreiningur kemur upp í kringum eina einingu, við sameiningu kóðans, er það leyst á sama hátt og í restinni af kóðanum
- Það eru snið sem eru keyrð eftir vel heppnaða flutning. Og þeir geta borið þjónustuaðgerðir. Síðasta uppfærsla var fyrir mánuði síðan, það er verkefnið er lifandi
Hvað varðar gallana, þá eru þeir hér:
- Engin sjálfvirk kynslóð fólksflutninga
- Engin tenging við EF gerðir
- Engar skyndimyndir af gagnagrunni
Hvert var val okkar?
Hinar heitu umræður snerust um tvo þætti - sjálfvirka myndun fólksflutninga og skynsamlega lausn átaka. Aðrir þættir voru mun minna ógnvekjandi. Í kjölfarið ákvað teymið, byggt á niðurstöðum umræðunnar, að nota Fluent Migrator í nýja verkefninu. Vegna þess að leysa ágreining í framtíðinni mun hafa mun meiri ávinning.
Niðurstöður
Auðvitað eru engin fullkomin verkfæri. Þannig að við urðum að forgangsraða „viljum“ okkar til að velja. Hins vegar, fyrir önnur teymi og önnur verkefni, geta aðrir þættir ráðið úrslitum. Við vonum að þessi grein muni hjálpa þér að velja.
Heimild: www.habr.com