Perbandingan lan pilihan sistem migrasi data
Model data cenderung diganti sajrone proses pangembangan, lan ing sawetara titik ora cocog maneh karo database. Mesthine, database bisa dibusak, lan banjur ORM bakal nggawe versi anyar sing bakal cocog karo model, nanging prosedur iki bakal nyebabake mundhut data sing wis ana. Mangkono, fungsi sistem migrasi yaiku kanggo mesthekake yen, minangka asil saka owah-owahan skema, disinkronake karo model data ing aplikasi tanpa kelangan data sing wis ana.
Ing artikel iki, kita pengin ndeleng macem-macem alat kanggo ngatur migrasi database. Muga-muga review iki bakal migunani kanggo pangembang sing ngadhepi pilihan sing padha.
Tujuan
Perusahaan kita saiki aktif ngembangake produk generasi sabanjure - Docs Security Suite (DSS). Bagian server ditulis ing .Net Core, lan Entity Framework Core digunakake minangka DBMS. Nalika ngrancang aplikasi, kita nggunakake pendekatan Code First.
Model domain aplikasi digawe dening sawetara pangembang ing wektu sing padha - saben tanggung jawab kanggo bagean logis dhewe saka sistem.
DSS generasi sadurunge nggunakake Entity Framework Migration (EF 6) klasik minangka sistem manajemen migrasi. Nanging, sawetara keluhan wis akumulasi, sing utama yaiku EF ora duwe pendekatan sing waras kanggo ngrampungake konflik versi. Kasunyatan iki isih ngganggu kita nalika ndandani kewan omo minangka bagean saka dhukungan, mula kita mutusake kanggo nimbang opsi alternatif.
Minangka asil diskusi, syarat ing ngisor iki kanggo sistem manajemen migrasi dibentuk:
- Dhukungan kanggo macem-macem DBMS. MS SQL Server, PostgreSQL, Oracle dibutuhake, nanging bisa uga nggunakake liyane
- Nggarap ORM. Kaping pisanan, direncanakake nggunakake EF Core, nanging ing tahap desain kita siap nimbang ORM liyane
- Generasi otomatis saka migrasi. Nganggep pangembangan Code First, aku pengin ngindhari migrasi "tulisan tangan".
- Konflik versi. Ing lingkungan pangembangan sing disebarake, nalika gabung, EF Core bisa nandhang konflik. Iki dadi masalah sing penting amarga macem-macem bagean aplikasi digawe dening pangembang sing beda-beda, dadi sampeyan kudu nglampahi akeh wektu kanggo saben
- Dokumentasi lan dhukungan lanjut. Ing kene, misale jek, ora ana panjelasan sing dibutuhake
- Gratis. Kriteria kasebut kondisional, amarga sistem ora larang banget utawa larang, nanging cocog kanggo kepenak, kita uga siap nimbang
Minangka asil riset cilik, opsi ing ngisor iki ditemokake lan ditemokake sing dikarepake kanggo dipikirake:
- Migrasi Inti EF
- DBup
- Gedung BunderE
- ThinkingHome.Migrator
- Migrator sing lancar
Lan saiki luwih rinci
Alami, iki minangka pilihan pisanan lan utama sing kudu dipilih. Instrumen asli sing dianggo metu saka kothak tanpa rebab. A jumlah gedhe saka dokumentasi, resmi lan ora supaya, gamblang, etc. Nanging, keluhan sing digawe babagan EF klasik uga cocog kanggo EF Core.
Dadi, kaluwihan kanggo EF Core disorot:
- Dhukungan Microsoft, dokumentasi, kalebu ing Rusia, komunitas gedhe
- Generasi otomatis migrasi adhedhasar CodeFirst
- Dibandhingake karo EF 6, EF Core ora nyimpen snapshot saka database maneh. Nalika nggarap EF Core ing Code First, ora perlu masang database maneh
- Awit kita lagi nari saka Code First, bisa nindakake siji migrasi menyang kabeh panyedhiya akses data sing dibutuhake
- Babagan panyedhiya, PostgreSQL didhukung, Oracle didhukung, lsp, lsp, lan malah MS SQL Server ο
Lan uga kekurangan:
- Resolusi konflik tetep ing tingkat sing padha. Sampeyan perlu kanggo urutan migrasi lan nganyari snapshot database
- Ketergantungan ing model sing digawe migrasi
DbUp
DbUp punika .NET perpustakaan sing diinstal dening NuGet lan mbantu push owah-owahan kanggo SQL Server. Iku nglacak skrip pangowahan sing wis ditindakake lan mbukak sing perlu kanggo nganyari database. Pustaka kasebut tuwuh saka proyek kanggo mesin blogging open source ing ASP.NET lan ana ing sangisore lisensi MIT, lan kode kasebut ana ing GitHub. Migrasi diterangake nggunakake T-SQL.
Apa kaluwihan:
- Dhukungan kanggo akeh DBMS (MS SQL Server, PstgreSQL, MySQL)
- Wiwit skrip ditulis ing T-SQL, katon cukup prasaja
- Konflik uga dirampungake nggunakake SQL
Lan cons:
- Kanthi kabeh macem-macem DBMS sing didhukung, Oracle ora dadi salah sawijining
- Ora sesambungan karo ORM
- Nulis skrip T-SQL kanthi tangan dudu tujuane
- Dokumentasi lan komunitas kaya-kaya, sanajan ing babagan nulis skrip SQL bisa uga ora perlu.
Gedung BunderE
Alat manajemen migrasi iki, disebarake miturut lisensi Apache 2.0, kaya sing sadurunge, mlaku ing mesin migrasi T-SQL. Ketoke, para pangembang luwih prioritas kanggo ngrampungake masalah teknis babagan dhukungan DBMS, tinimbang nggawe proses pangembangan sing nyenengake.
Pros:
- Ndhukung DBMS sing dibutuhake (kalebu Oracle)
Cons:
- Oracle (uga Akses, sing ora cocog kanggo kita) ora didhukung ing .NET Core, mung ing .NET Full Framework
- Ora bisa digunakake karo ORM
- Ana dokumentasi malah kurang saka alat sadurunge
- Maneh - migrasi ditulis kanthi skrip
ThinkingHome.Migrator
Alat kanggo migrasi skema database versi menyang platform .NET Core, disebarake miturut lisensi MIT. .
Pros:
- Dirancang kanggo .NET Core
- Dilaksanakake urutan percabangan migrasi
- Dilaksanakake logging migrasi
Cons:
- Dianyari pungkasan setahun kepungkur. Ketoke proyek kasebut ora didhukung
- Ora didhukung dening Oracle (artikel kasebut nyatakake yen iki amarga ora ana implementasine stabil kanggo .NET Core - nanging iki setaun kepungkur)
- Ora ana generasi migrasi otomatis
Sakabèhé, proyek kasebut katon janjeni, utamane yen bakal dikembangake, nanging kita kudu nggawe keputusan ing kene lan saiki.
Migrator sing lancar
Alat migrasi sing paling populer kanthi tentara penggemar sing akeh. Didistribusikake miturut lisensi Apache 2.0. Minangka kasebut ing gambaran, iku framework migrasi kanggo .NET, padha karo Ruby on Rails Migration. Owah-owahan ing skema database diterangake ing C # kelas.
Ana kaluwihan ing kene:
- Dhukungan kanggo DBMS sing dibutuhake
- Dhukungan .NET Core
- Komunitas sing dikembangake gedhe
- Konflik antarane migrasi dirampungake kanthi urutan-urutan eksekusi migrasi wis ditemtokake. Kajaba iku, yen konflik muncul ing saubengΓ© siji entitas, nalika nggabungake kode kasebut, bakal dirampungake kanthi cara sing padha karo kode liyane.
- Ana profil sing dieksekusi sawise migrasi sukses. Lan bisa nindakake fungsi layanan. Nganyari pungkasan ana wulan kepungkur, yaiku, proyek kasebut urip
Kanggo minus, ing ngisor iki:
- Ora ana generasi migrasi otomatis
- Ora ana sambungan karo model EF
- Ora ana snapshot database
Apa pilihan kita?
Debat sing digawe panas ngubengi rong parameter - migrasi otomatis lan resolusi konflik sing waras. Faktor liyane padha kurang medeni. AkibatΓ©, adhedhasar asil diskusi, tim mutusake nggunakake Fluent Migrator ing proyek anyar. Amarga ngrampungake konflik ing mangsa ngarep bakal nggawa keuntungan sing luwih akeh.
temonan
Mesthi, ora ana alat sing sampurna. Dadi kita kudu menehi prioritas "kepengin" kanggo nggawe pilihan. Nanging, kanggo tim liyane lan tugas liyane, faktor liya bisa uga dadi penentu. Muga-muga artikel iki bakal mbantu sampeyan nggawe pilihan.
Source: www.habr.com