Ulinganisho na uteuzi wa mifumo ya uhamiaji wa data
Mfano wa data huelekea kubadilika wakati wa mchakato wa maendeleo, na wakati fulani haufanani tena na hifadhidata. Bila shaka, hifadhidata inaweza kufutwa, na kisha ORM itaunda toleo jipya ambalo litafanana na mfano, lakini utaratibu huu utasababisha kupoteza data zilizopo. Kwa hivyo, kazi ya mfumo wa uhamiaji ni kuhakikisha kuwa, kama matokeo ya mabadiliko ya schema, inasawazishwa na mfano wa data katika programu bila kupoteza data iliyopo.
Katika makala haya, tungependa kuangalia zana mbalimbali za kudhibiti uhamaji wa hifadhidata. Tunatumahi kuwa ukaguzi huu utakuwa muhimu kwa wasanidi programu wanaokabiliwa na chaguo sawa.
Kazi
Kampuni yetu kwa sasa inaendeleza kikamilifu kizazi kijacho cha bidhaa - Docs Security Suite (DSS). Sehemu ya seva imeandikwa katika .Net Core, na Entity Framework Core inatumika kama DBMS. Wakati wa kuunda programu, tunatumia mbinu ya Kanuni ya Kwanza.
Mfano wa kikoa cha maombi huundwa na watengenezaji kadhaa kwa wakati mmoja - kila mmoja anajibika kwa sehemu yake ya mantiki ya mfumo.
Kizazi cha awali cha DSS kilitumia Uhamishaji wa Mfumo wa Kawaida wa Taasisi (EF 6) kama mfumo wa usimamizi wa uhamiaji. Hata hivyo, baadhi ya malalamiko yamekusanyika dhidi yake, kuu ni kwamba EF haina mbinu timamu ya kutatua migogoro ya matoleo. Ukweli huu bado hutufadhaisha tunaporekebisha hitilafu kama sehemu ya usaidizi, kwa hivyo tuliamua kuzingatia chaguo mbadala.
Kama matokeo ya majadiliano, mahitaji yafuatayo ya mfumo wa usimamizi wa uhamiaji yaliundwa:
- Msaada kwa DBMS mbalimbali. Seva ya MS SQL, PostgreSQL, Oracle inahitajika, lakini kuna uwezekano wa kutumia zingine
- Kufanya kazi na ORM. Hapo awali, ilipangwa kutumia EF Core, lakini katika hatua ya kubuni tulikuwa tayari kuzingatia ORM nyingine
- Uzalishaji otomatiki wa uhamiaji. Kwa kuzingatia ukuzaji wa Kanuni Kwanza, ningependa kuzuia hitaji la "kuandika kwa mkono" uhamiaji.
- Migogoro ya matoleo. Katika mazingira ya maendeleo yaliyosambazwa, wakati wa kuunganisha, EF Core inaweza kuteseka kutokana na migogoro. Hili huwa tatizo kubwa kwa sababu sehemu tofauti za programu huundwa na watengenezaji tofauti, kwa hivyo lazima utumie muda mwingi kwa kila moja.
- Nyaraka za hali ya juu na usaidizi. Hapa, inaonekana kwetu, hakuna maelezo inahitajika
- Bure. Kigezo ni cha masharti, kwani mifumo sio ghali sana au ghali, lakini inafaa kwa urahisi, tulikuwa tayari kuzingatia.
Kama matokeo ya utafiti mdogo, chaguzi zifuatazo zilipatikana na zikapatikana zinafaa kuzingatiwa:
- Uhamiaji wa Msingi wa EF
- DBup
- Nyumba ya pande zoteE
- ThinkingHome.Migrator
- Mhamiaji Fasaha
Na sasa maelezo zaidi kidogo
Kwa kawaida, hii ilikuwa chaguo la kwanza na kuu la kuchagua. Ala asili inayofanya kazi nje ya kisanduku bila kuchezea tari. Kiasi kikubwa cha nyaraka, rasmi na sivyo, unyenyekevu, nk. Walakini, malalamiko yaliyotolewa kuhusu EF ya kawaida pia yanafaa kabisa kwa EF Core.
Kwa hivyo, faida za EF Core zimesisitizwa:
- Usaidizi wa Microsoft, nyaraka, ikiwa ni pamoja na katika Kirusi, jumuiya kubwa
- Uzalishaji kiotomatiki wa uhamiaji kulingana na CodeFirst
- Ikilinganishwa na EF 6, EF Core haihifadhi tena muhtasari wa hifadhidata. Wakati wa kufanya kazi na EF Core katika Kanuni ya Kwanza, si lazima tena kupeleka hifadhidata
- Kwa kuwa tunacheza kutoka kwa Kanuni ya Kwanza, inawezekana kufanya uhamishaji mmoja kwa watoa huduma wote wanaohitajika wa kufikia data
- Kuhusu watoa huduma, PostgreSQL inaauniwa, Oracle inatumika, n.k., nk, na hata Seva ya MS SQL ο
Na pia hasara:
- Utatuzi wa migogoro ulibaki katika kiwango sawa. Ni muhimu kupanga uhamiaji na kusasisha vijipicha vya hifadhidata
- Utegemezi wa mifano ambayo uhamiaji hutolewa
DbUp
DbUp ni maktaba ya .NET ambayo imesakinishwa na NuGet na husaidia kusukuma mabadiliko kwenye Seva ya SQL. Hufuatilia ni hati zipi za mabadiliko tayari zimetekelezwa na huendesha zile ambazo ni muhimu kusasisha hifadhidata. Maktaba ilikua kama mradi wa injini ya kublogi ya chanzo wazi kwenye ASP.NET na inapatikana chini ya leseni ya MIT, na nambari hiyo iko kwenye GitHub. Uhamiaji unaelezewa kwa kutumia T-SQL.
Je, ni faida gani:
- Msaada kwa idadi kubwa ya DBMS (MS SQL Server, PstgreSQL, MySQL)
- Kwa kuwa maandishi yameandikwa katika T-SQL, yanaonekana rahisi sana
- Migogoro pia hutatuliwa kwa kutumia SQL
Na hasara:
- Pamoja na aina zote za DBMS zinazotumika, Oracle sio mojawapo
- Haiingiliani na ORM
- Kuandika hati za T-SQL kwa mkono sio kile tulikuwa tunalenga
- Nyaraka na jumuiya ni hivyo-hivyo, ingawa katika suala la kuandika hati za SQL huenda zisiwe za lazima.
Nyumba ya pande zoteE
Zana hii ya usimamizi wa uhamiaji, inayosambazwa chini ya leseni ya Apache 2.0, kama ile ya awali, inaendeshwa kwenye injini ya uhamiaji ya T-SQL. Inavyoonekana, watengenezaji walitanguliza utatuzi wa matatizo ya kiufundi kuhusu usaidizi wa DBMS, badala ya kuunda mchakato mzuri wa maendeleo.
Faida:
- Inasaidia DBMS muhimu (pamoja na Oracle)
Minus:
- Oracle (pamoja na Ufikiaji, ambayo sio muhimu kwetu) haitumiki kwenye .NET Core, kwenye .NET Full Framework pekee.
- Haifanyi kazi na ORM
- Kuna hati hata kidogo kuliko zana iliyotangulia
- Tena - uhamiaji umeandikwa na maandishi
ThinkingHome.Migrator
Zana ya uhamishaji wa schema ya hifadhidata iliyotolewa hadi kwenye jukwaa la NET Core, inayosambazwa chini ya leseni ya MIT. .
Faida:
- Imeundwa kwa ajili ya .NET Core
- Imetekelezwa mlolongo wa matawi ya uhamiaji
- Uwekaji kumbukumbu wa uhamiaji umetekelezwa
Minus:
- Ilisasishwa mwisho mwaka mmoja uliopita. Inaonekana mradi hautumiki
- Haiungwi mkono na Oracle (kifungu kinasema kwamba hii ni kwa sababu ya ukosefu wa utekelezaji thabiti wa NET Core - lakini hii ni mwaka mmoja uliopita)
- Hakuna kizazi kiotomatiki cha uhamiaji
Kwa ujumla, mradi unaonekana kuahidi, hasa ikiwa ungeendelezwa, lakini tulihitaji kufanya uamuzi hapa na sasa.
Mhamiaji Fasaha
Chombo maarufu cha uhamiaji na jeshi kubwa la mashabiki. Inasambazwa chini ya leseni ya Apache 2.0. Kama ilivyoelezwa katika maelezo, ni mfumo wa uhamiaji wa .NET, sawa na Ruby on Rails Migration. Mabadiliko ya schema ya hifadhidata yameelezewa katika madarasa ya C #.
Kuna faida hapa:
- Usaidizi kwa DBMS inayohitajika
- Usaidizi wa NET Core
- Jumuiya kubwa iliyoendelea
- Migogoro kati ya uhamiaji hutatuliwa kwa kufuatana-utaratibu wa utekelezaji wa uhamiaji umebainishwa. Kwa kuongeza, ikiwa mgogoro unatokea karibu na chombo kimoja, wakati wa kuunganisha msimbo, unatatuliwa kwa njia sawa na katika kanuni nyingine.
- Kuna wasifu ambao hutekelezwa baada ya uhamiaji uliofanikiwa. Na wanaweza kubeba utendakazi wa huduma.Sasisho la mwisho lilikuwa mwezi mmoja uliopita, yaani, mradi uko hai
Kuhusu minuses, hapa ni:
- Hakuna kizazi kiotomatiki cha uhamiaji
- Hakuna muunganisho na miundo ya EF
- Hakuna vijipicha vya hifadhidata
Chaguo letu lilikuwa nini?
Mijadala mikali ilihusu vigezo viwili - kizazi kiotomatiki cha uhamiaji na utatuzi mzuri wa migogoro. Mambo mengine hayakuwa ya kutisha sana. Kama matokeo, kwa kuzingatia matokeo ya majadiliano, timu iliamua kutumia Uhamiaji Fasaha katika mradi mpya. Kwa sababu kusuluhisha mizozo katika siku zijazo kutaleta faida nyingi zaidi.
Matokeo
Bila shaka, hakuna zana kamili. Kwa hivyo ilitubidi kutanguliza "matakwa" yetu kufanya uchaguzi. Walakini, kwa timu zingine na kazi zingine, mambo mengine yanaweza kuwa ya kuamua. Tunatarajia makala hii itakusaidia kufanya uchaguzi.
Chanzo: mapenzi.com