Geekly articles weekly

Perbandingan dan pemilihan sistem migrasi data

Perbandingan dan pemilihan sistem migrasi data




Model data dalam proses pengembangan memiliki properti untuk berubah, dan pada titik tertentu tidak lagi sesuai dengan database. Tentu saja, basis data dapat dihapus, dan kemudian ORM akan membuat versi baru yang akan sesuai dengan model, tetapi prosedur seperti itu akan menyebabkan hilangnya data yang ada. Dengan demikian, fungsi dari sistem migrasi adalah untuk memastikan bahwa, sebagai akibat dari mengubah skema, menyinkronkannya dengan model data dalam aplikasi tanpa kehilangan data yang ada.

Dalam artikel ini, kami ingin mempertimbangkan berbagai alat untuk mengelola migrasi basis data. Kami berharap ulasan ini bermanfaat bagi pengembang yang dihadapkan dengan pilihan ini.

Tantangan


Perusahaan kami saat ini sedang aktif mengembangkan produk generasi berikutnya - Docs Security Suite (DSS). Bagian server ditulis pada .Net Core, dan Entity Framework Core masing-masing digunakan sebagai DBMS. Saat merancang aplikasi, kami menggunakan pendekatan Code First.

Model domain dari aplikasi ini dibuat oleh beberapa pengembang secara bersamaan - masing-masing bertanggung jawab atas bagian logisnya dari sistem.

Dalam generasi DSS sebelumnya, Migrasi Entitas Kerangka kerja klasik (EF 6) digunakan sebagai sistem manajemen migrasi. Namun, beberapa klaim telah terakumulasi menentangnya, yang utamanya adalah EF tidak memiliki pendekatan yang waras untuk menyelesaikan konflik versi. Fakta ini masih mengecewakan kami ketika memperbaiki bug dalam kerangka dukungan, jadi diputuskan untuk mempertimbangkan opsi alternatif.

Sebagai hasil dari diskusi, persyaratan berikut untuk sistem manajemen migrasi dibentuk:

  1. Dukungan untuk berbagai DBMS. Wajib MS SQL Server, PostgreSQL, Oracle, tetapi Anda berpotensi menggunakan yang lain
  2. Bekerja dengan ORM. Awalnya, penggunaan EF Core seharusnya, tetapi pada tahap desain, ORM lain siap untuk dipertimbangkan
  3. Autogenerasi migrasi. Mengingat pengembangan Kode Pertama, saya ingin menghindari kebutuhan untuk "melukis dengan pena" migrasi
  4. Konflik versi. Dalam lingkungan pengembangan terdistribusi dengan penggabungan, EF Core dapat mengalami konflik. Ini menjadi masalah yang signifikan, karena bagian aplikasi yang berbeda dibuat oleh pengembang yang berbeda, sehingga Anda harus menghabiskan banyak waktu untuk setiap aplikasi.
  5. Dokumentasi dan dukungan tingkat lanjut. Di sini, menurut kami, tidak diperlukan penjelasan
  6. Gratis. Kriteria bersyarat, karena bukan sistem yang sangat mahal atau mahal, tetapi ideal dalam kenyamanan, kami juga siap untuk mempertimbangkan

Sebagai hasil dari studi kecil, opsi berikut ditemukan dan dianggap diinginkan untuk dipertimbangkan:

  1. Migrasi inti
  2. Dbup
  3. RoundhousE
  4. ThinkingHome.Migrator
  5. Migrator yang lancar

Dan sekarang sedikit lagi



Migrasi Inti EntityFramework

Secara alami, ini adalah pilihan pertama dan utama untuk pilihan. Alat asli yang bekerja di luar kotak tanpa menari dengan rebana. Sejumlah besar dokumentasi, resmi dan tidak terlalu, kesederhanaan, dll. Namun, klaim yang disampaikan kepada EF klasik cukup relevan untuk EF Core.

Dengan demikian, keuntungan untuk EF Core disorot:

  • Dukungan Microsoft, dokumentasi, termasuk dalam bahasa Rusia, komunitas besar
  • Migrasi Otomatis Berbasis CodeFirst
  • Dibandingkan dengan EF 6, snapshot basis data tidak lagi disimpan di EF Core. Saat bekerja dengan EF Core di Code First, Anda tidak perlu lagi menggunakan basis data
  • Karena kita menari dari Code First - dimungkinkan untuk melakukan satu migrasi ke semua penyedia akses data yang diperlukan
  • Mengenai penyedia - PostgreSQL, Oracle, dll., Dll., Dan bahkan - MS SQL Server didukung

Serta kontra:

  • Resolusi konflik tetap pada tingkat yang sama. Kita perlu membangun urutan migrasi dan memperbarui gambar basis data
  • Ketergantungan pada model berdasarkan migrasi yang dihasilkan

Dbup


dbup.imtqy.com

DbUp adalah pustaka .NET yang diinstal oleh NuGet dan membantu untuk memutar perubahan ke SQL Server. Ini melacak perubahan skrip yang telah dijalankan, dan meluncurkan yang diperlukan untuk memperbarui database. Perpustakaan tumbuh dari proyek mesin blog sumber terbuka ASP.NET dan ada di bawah lisensi MIT, dan kode ada di GitHub. Migrasi dijelaskan menggunakan T-SQL.

Apa kelebihannya:

  • Dukungan untuk sejumlah besar DBMS (MS SQL Server, PstgreSQL, MySQL)
  • Karena skrip ditulis dalam T-SQL, skrip tersebut terlihat sangat sederhana
  • Konflik juga diselesaikan dengan menggunakan SQL

Kontra:

  • Dengan semua variasi DBMS yang didukung, Oracle tidak ada di antara mereka.
  • Tidak berinteraksi dengan ORM
  • Menulis skrip T-SQL dengan pulpen bukanlah tujuan kami
  • Dokumentasi dan komunitasnya biasa saja, walaupun mungkin tidak diperlukan dalam konteks penulisan skrip SQL.

RoundhousE


github.com/chucknorris/roundhouse

Alat manajemen migrasi ini, didistribusikan di bawah lisensi Apache 2.0, seperti yang sebelumnya, berjalan pada mesin migrasi T-SQL. Tampaknya, para pengembang fokus pada pemecahan masalah teknis mengenai dukungan DBMS, daripada menciptakan proses pengembangan yang nyaman.

Pro:

  • Mendukung DBMS yang diperlukan (termasuk Oracle)

Cons:

  • Oracle (dan juga Access tidak relevan bagi kami) tidak didukung pada .NET Core, hanya pada .NET Full Framework
  • Tidak bekerja dengan ORM
  • Bahkan ada lebih sedikit dokumentasi daripada alat sebelumnya
  • Lagi - migrasi ditulis dalam skrip

ThinkingHome.Migrator



Alat untuk migrasi versi skema database untuk platform .NET Core, didistribusikan di bawah lisensi MIT. Pengembang sendiri menulis tentang versi terbaru hampir setahun yang lalu .

Pro:

  • Dipertajam di bawah .NET Core
  • Diimplementasikan urutan migrasi bercabang
  • Pencatatan migrasi yang diterapkan

Cons:

  • Pembaruan terakhir - setahun yang lalu. Rupanya, proyek itu tidak didukung.
  • Tidak didukung oleh Oracle (artikel ini menyatakan bahwa ini disebabkan oleh kurangnya implementasi yang stabil untuk .NET Core - tetapi ini setahun yang lalu)
  • Migrasi auto-generasi tidak ada

Secara umum, proyek ini terlihat menjanjikan, terutama jika itu akan berkembang, tetapi kami perlu membuat keputusan di sini dan sekarang.

Migrator yang lancar


github.com/fluentmigrator/fluentmigrator

Alat migrasi paling populer dengan sepasukan besar penggemar. Didistribusikan di bawah lisensi Apache 2.0. Seperti yang dinyatakan dalam deskripsi, ini adalah platform migrasi untuk .NET, mirip dengan Ruby on Rails Migrations. Perubahan pada skema database dijelaskan dalam kelas di C #.

Ada plus:

  • Dukungan untuk DBMS yang diperlukan
  • Dukungan Inti NET
  • Komunitas maju yang besar
  • Konflik migrasi diselesaikan secara berurutan - urutan eksekusi diindikasikan untuk migrasi. Selain itu, jika ada konflik di sekitar satu entitas, saat menggabungkan kode, solusinya dilakukan dengan cara yang sama seperti di sisa kode
  • Ada profil yang berjalan setelah migrasi berhasil. Dan mereka dapat menjalankan fungsi layanan. Pembaruan terakhir adalah sebulan yang lalu, yaitu, proyek tetap hidup

Adapun kontra, di sini:

  • Migrasi auto-generasi tidak ada
  • Tidak ada koneksi dengan model EF
  • Tidak ada snapshot basis data

Apa pilihan kita?




Debat yang paling panas berkisar pada dua parameter - auto-generation of migrasi dan resolusi konflik yang waras. Faktor-faktor lain jauh lebih sedikit ditakuti. Akibatnya, sebagai hasil diskusi, tim memutuskan untuk menggunakan Fluent Migrator dalam proyek baru. Untuk penyelesaian konflik di masa depan akan membawa keuntungan lebih banyak.

Kesimpulan


Tentu saja, tidak ada alat yang sempurna. Jadi kami harus memprioritaskan "Daftar Keinginan" kami untuk suatu pilihan. Namun, faktor-faktor lain mungkin menentukan untuk tim lain dan tugas lainnya. Kami harap artikel ini membantu Anda menentukan pilihan.

Source: https://habr.com/ru/post/id453930/

More articles:


All Articles