Paghahambing at pagpili ng mga data migration system
Ang modelo ng data ay may posibilidad na magbago sa panahon ng proseso ng pag-unlad, at sa ilang mga punto ay hindi na ito tumutugma sa database. Siyempre, maaaring tanggalin ang database, at pagkatapos ay gagawa ang ORM ng bagong bersyon na tutugma sa modelo, ngunit ang pamamaraang ito ay hahantong sa pagkawala ng umiiral na data. Kaya, ang function ng migration system ay upang matiyak na, bilang resulta ng isang schema change, ito ay naka-synchronize sa data model sa application nang hindi nawawala ang umiiral na data.
Sa artikulong ito, gusto naming tingnan ang iba't ibang mga tool para sa pamamahala ng mga paglilipat ng database. Umaasa kami na ang pagsusuri na ito ay magiging kapaki-pakinabang para sa mga developer na nahaharap sa isang katulad na pagpipilian.
Gawain
Ang aming kumpanya ay kasalukuyang aktibong gumagawa ng susunod na henerasyon ng produkto β Docs Security Suite (DSS). Ang bahagi ng server ay nakasulat sa .Net Core, at Entity Framework Core ay ginagamit bilang DBMS. Kapag nagdidisenyo ng isang application, ginagamit namin ang Code First approach.
Ang modelo ng domain ng application ay nilikha ng ilang mga developer nang sabay-sabay - bawat isa ay responsable para sa kanilang sariling lohikal na bahagi ng system.
Ginamit ng nakaraang henerasyon ng DSS ang classic na Entity Framework Migrations (EF 6) bilang ang migration management system. Gayunpaman, ang ilang mga reklamo ay naipon laban dito, ang pangunahing isa ay ang EF ay walang tamang diskarte sa paglutas ng mga salungatan sa bersyon. Nakakainis pa rin sa amin ang katotohanang ito kapag nag-aayos ng mga bug bilang bahagi ng suporta, kaya nagpasya kaming isaalang-alang ang mga alternatibong opsyon.
Bilang resulta ng talakayan, nabuo ang mga sumusunod na kinakailangan para sa sistema ng pamamahala ng paglipat:
- Suporta para sa iba't ibang DBMS. MS SQL Server, PostgreSQL, Oracle ay kinakailangan, ngunit ito ay potensyal na posible na gumamit ng iba
- Nagtatrabaho sa ORM. Noong una, binalak itong gumamit ng EF Core, ngunit sa yugto ng disenyo ay handa kaming isaalang-alang ang iba pang mga ORM
- Auto-generation ng mga migrasyon. Isinasaalang-alang ang pagbuo ng Code First, gusto kong iwasan ang pangangailangang "isulat-kamay" ang mga paglilipat
- Mga salungatan sa bersyon. Sa isang distributed development environment, kapag nagsasama, ang EF Core ay maaaring magdusa mula sa mga salungatan. Nagiging malaking problema ito dahil ang iba't ibang bahagi ng application ay nilikha ng iba't ibang mga developer, kaya kailangan mong gumugol ng maraming oras sa bawat isa.
- Advanced na dokumentasyon at suporta. Dito, tila sa amin, walang paliwanag ang kailangan
- Libre. Ang pamantayan ay may kondisyon, dahil ang mga system ay hindi masyadong mahal o mahal, ngunit perpekto sa kaginhawahan, handa rin kaming isaalang-alang
Bilang resulta ng isang maliit na pananaliksik, ang mga sumusunod na opsyon ay natagpuan at nakitang kanais-nais para sa pagsasaalang-alang:
- EF Core Migration
- DBup
- RoundhouseE
- ThinkingHome.Migrator
- Matatas na Migrator
At ngayon ng kaunti pang detalye
Naturally, ito ang una at pangunahing pagpipilian na pipiliin. Isang katutubong instrumento na gumagana sa labas ng kahon nang walang anumang kalikot sa paligid ng tamburin. Ang isang malaking halaga ng dokumentasyon, opisyal at hindi ganoon, pagiging simple, atbp. Gayunpaman, ang mga reklamong ginawa tungkol sa classic na EF ay medyo may kaugnayan din para sa EF Core.
Kaya, ang mga pakinabang para sa EF Core ay naka-highlight:
- Suporta ng Microsoft, dokumentasyon, kabilang sa Russian, malaking komunidad
- Awtomatikong pagbuo ng mga paglilipat batay sa CodeFirst
- Kung ikukumpara sa EF 6, hindi na nag-iimbak ang EF Core ng snapshot ng database. Kapag nagtatrabaho sa EF Core sa Code First, hindi na kailangang mag-deploy ng database
- Dahil sumasayaw kami mula sa Code First, posibleng magsagawa ng isang paglipat sa lahat ng kinakailangang provider ng pag-access ng data
- Tungkol sa mga provider, sinusuportahan ang PostgreSQL, sinusuportahan ang Oracle, atbp., atbp., at maging ang MS SQL Server ο
At din ang mga disadvantages:
- Ang paglutas ng salungatan ay nanatili sa parehong antas. Kinakailangang i-sequence ang mga migrasyon at i-update ang mga snapshot ng database
- Dependency sa mga modelo kung saan nabuo ang mga paglilipat
DbUp
Ang DbUp ay isang .NET library na na-install ng NuGet at tumutulong na itulak ang mga pagbabago sa SQL Server. Sinusubaybayan nito kung aling mga script ng pagbabago ang naisakatuparan at pinapatakbo ang mga kinakailangan upang i-update ang database. Ang library ay lumago mula sa isang proyekto para sa isang open source na blogging engine sa ASP.NET at umiiral sa ilalim ng isang lisensya ng MIT, at ang code ay nasa GitHub. Ang mga paglilipat ay inilarawan gamit ang T-SQL.
Ano ang mga pakinabang:
- Suporta para sa isang malaking bilang ng DBMS (MS SQL Server, PstgreSQL, MySQL)
- Dahil ang mga script ay nakasulat sa T-SQL, mukhang medyo simple ang mga ito
- Ang mga salungatan ay nareresolba din gamit ang SQL
At ang kahinaan:
- Sa lahat ng iba't ibang mga suportadong DBMS, ang Oracle ay hindi isa sa kanila
- Hindi nakikipag-ugnayan sa ORM
- Ang pagsulat ng mga T-SQL script sa pamamagitan ng kamay ay hindi ang aming nilalayon
- Ang dokumentasyon at komunidad ay ganoon-ganoon, bagaman sa mga tuntunin ng pagsulat ng mga script ng SQL ay maaaring hindi sila kinakailangan.
RoundhouseE
Ang tool sa pamamahala ng paglipat na ito, na ipinamahagi sa ilalim ng lisensya ng Apache 2.0, tulad ng nauna, ay tumatakbo sa T-SQL migration engine. Tila, inuna ng mga developer ang paglutas ng mga teknikal na problema tungkol sa suporta sa DBMS, sa halip na lumikha ng komportableng proseso ng pag-unlad.
Pros:
- Sinusuportahan ang kinakailangang DBMS (kabilang ang Oracle)
Cons:
- Ang Oracle (pati na rin ang Access, na hindi nauugnay para sa amin) ay hindi suportado sa .NET Core, sa .NET Full Framework lang.
- Hindi gumagana sa ORM
- Mayroong mas kaunting dokumentasyon kaysa sa nakaraang tool
- Muli β ang mga migrasyon ay isinulat ng mga script
ThinkingHome.Migrator
Isang tool para sa versioned database schema migration sa .NET Core platform, na ipinamahagi sa ilalim ng lisensya ng MIT. .
Pros:
- Idinisenyo para sa .NET Core
- Nagpatupad ng sumasanga na pagkakasunod-sunod ng mga paglilipat
- Ipinatupad ang migration logging
Cons:
- Huling na-update noong isang taon. Tila ang proyekto ay hindi suportado
- Hindi suportado ng Oracle (ang artikulo ay nagsasaad na ito ay dahil sa kakulangan ng isang matatag na pagpapatupad para sa .NET Core - ngunit ito ay isang taon na ang nakalipas)
- Walang awtomatikong henerasyon ng mga paglilipat
Sa pangkalahatan, ang proyekto ay mukhang may pag-asa, lalo na kung ito ay bubuo, ngunit kailangan naming gumawa ng desisyon dito at ngayon.
Matatas na Migrator
Ang pinakasikat na tool sa paglilipat na may malaking hukbo ng mga tagahanga. Ibinahagi sa ilalim ng lisensya ng Apache 2.0. Gaya ng nakasaad sa paglalarawan, isa itong balangkas ng paglipat para sa .NET, katulad ng Ruby on Rails Migrations. Ang mga pagbabago sa schema ng database ay inilarawan sa mga klase ng C#.
Mayroong mga pakinabang dito:
- Suporta para sa kinakailangang DBMS
- .NET Core na suporta
- Malaking maunlad na pamayanan
- Ang mga salungatan sa pagitan ng mga migrasyon ay nareresolba nang sunud-sunodβang pagkakasunud-sunod ng pagpapatupad ng mga paglilipat ay tinukoy. Bilang karagdagan, kung ang isang salungatan ay lumitaw sa paligid ng isang entity, kapag pinagsama ang code, ito ay nalutas sa parehong paraan tulad ng sa natitirang bahagi ng code.
- May mga profile na naisakatuparan pagkatapos ng matagumpay na paglipat. At maaari silang magdala ng mga function ng serbisyo. Ang huling pag-update ay isang buwan na ang nakalipas, ibig sabihin, buhay ang proyekto
Tulad ng para sa mga minus, narito ang mga ito:
- Walang awtomatikong henerasyon ng mga paglilipat
- Walang koneksyon sa mga modelo ng EF
- Walang mga snapshot ng database
Ano ang aming napili?
Ang mainit na mga debate ay umikot sa dalawang parameter - awtomatikong pagbuo ng mga paglilipat at matino na paglutas ng mga salungatan. Ang iba pang mga kadahilanan ay hindi gaanong nakakatakot. Bilang resulta, batay sa mga resulta ng talakayan, nagpasya ang koponan na gamitin ang Fluent Migrator sa bagong proyekto. Dahil ang paglutas ng mga salungatan sa hinaharap ay magdadala ng higit pang mga benepisyo.
Natuklasan
Siyempre, walang perpektong tool. Kaya kinailangan naming unahin ang aming mga "gusto" na pumili. Gayunpaman, para sa iba pang mga koponan at iba pang mga gawain, ang iba pang mga kadahilanan ay maaaring maging mapagpasyahan. Umaasa kami na ang artikulong ito ay makakatulong sa iyo na pumili.
Pinagmulan: www.habr.com