Perbandingan dan pemilihan sistem migrasi data
Model data cenderung berubah selama proses pengembangan, dan pada titik tertentu tidak lagi sesuai dengan database. Tentu saja, database dapat dihapus, dan kemudian ORM akan membuat versi baru yang sesuai dengan modelnya, namun prosedur ini akan menyebabkan hilangnya data yang ada. Dengan demikian, fungsi sistem migrasi adalah untuk memastikan bahwa akibat perubahan skema, tersinkronisasi dengan model data dalam aplikasi tanpa kehilangan data yang ada.
Pada artikel ini, kami ingin melihat berbagai alat untuk mengelola migrasi database. Kami berharap ulasan ini bermanfaat bagi pengembang yang dihadapkan pada pilihan serupa.
Tugas
Perusahaan kami saat ini sedang aktif mengembangkan produk generasi berikutnya – Docs Security Suite (DSS). Bagian server ditulis dalam .Net Core, dan Entity Framework Core digunakan sebagai DBMS. Saat merancang aplikasi, kami menggunakan pendekatan Code First.
Model domain aplikasi dibuat oleh beberapa pengembang secara bersamaan - masing-masing bertanggung jawab atas bagian logis sistemnya sendiri.
DSS generasi sebelumnya menggunakan Entity Framework Migrations (EF 6) klasik sebagai sistem manajemen migrasi. Namun, beberapa keluhan telah terakumulasi terhadap hal ini, yang utama adalah bahwa EF tidak memiliki pendekatan yang masuk akal untuk menyelesaikan konflik versi. Fakta ini masih membuat kami kesal ketika memperbaiki bug sebagai bagian dari dukungan, jadi kami memutuskan untuk mempertimbangkan opsi alternatif.
Dari hasil diskusi, terbentuklah persyaratan sistem manajemen migrasi sebagai berikut:
- Dukungan untuk berbagai DBMS. MS SQL Server, PostgreSQL, Oracle diperlukan, tetapi ada kemungkinan untuk menggunakan yang lain
- Bekerja dengan ORM. Awalnya direncanakan untuk menggunakan EF Core, namun pada tahap desain kami siap mempertimbangkan ORM lainnya
- Migrasi yang dibuat secara otomatis. Dengan mempertimbangkan pengembangan Code First, saya ingin menghindari kebutuhan untuk migrasi “tulis tangan”.
- Konflik versi. Dalam lingkungan pengembangan terdistribusi, ketika digabungkan, 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 bagiannya.
- Dokumentasi dan dukungan tingkat lanjut. Di sini, menurut kami, tidak diperlukan penjelasan
- Bebas. Kriterianya bersyarat, karena sistemnya tidak terlalu mahal atau mahal, tetapi ideal dalam hal kenyamanan, kami juga siap mempertimbangkannya
Sebagai hasil dari sedikit riset, opsi berikut ditemukan dan dianggap layak untuk dipertimbangkan:
- Migrasi Inti EF
- DBup
- Gedung BundarE
- ThinkingHome.Migrator
- Migrator Lancar
Dan sekarang sedikit lebih detail
Tentu saja, ini adalah pilihan pertama dan utama yang harus dipilih. Instrumen asli yang dapat digunakan tanpa harus mengutak-atik rebana. Sejumlah besar dokumentasi, resmi dan tidak resmi, kesederhanaan, dll. Namun, keluhan yang dibuat mengenai EF klasik juga cukup relevan untuk EF Core.
Oleh karena itu, keunggulan EF Core disorot:
- Dukungan Microsoft, dokumentasi, termasuk dalam bahasa Rusia, komunitas besar
- Migrasi yang dibuat secara otomatis berdasarkan CodeFirst
- Dibandingkan dengan EF 6, EF Core tidak lagi menyimpan snapshot database. Saat bekerja dengan EF Core di Code First, penerapan database tidak lagi diperlukan
- Karena kami menggunakan Code First, dimungkinkan untuk melakukan satu migrasi ke semua penyedia akses data yang diperlukan
- Mengenai penyedia, PostgreSQL didukung, Oracle didukung, dll., dll., dan bahkan MS SQL Server
Dan juga kekurangannya:
- Resolusi konflik tetap pada tingkat yang sama. Penting untuk mengurutkan migrasi dan memperbarui snapshot database
- Ketergantungan pada model tempat migrasi dihasilkan
DbUp
DbUp adalah perpustakaan .NET yang diinstal oleh NuGet dan membantu mendorong perubahan pada SQL Server. Ini melacak skrip perubahan mana yang telah dijalankan dan menjalankan skrip perubahan yang diperlukan untuk memperbarui database. Perpustakaan ini tumbuh dari proyek mesin blog sumber terbuka di ASP.NET dan berada di bawah lisensi MIT, dan kodenya ada di GitHub. Migrasi dijelaskan menggunakan T-SQL.
Apa kelebihannya:
- Dukungan untuk sejumlah besar DBMS (MS SQL Server, PstgreSQL, MySQL)
- Karena skripnya ditulis dalam T-SQL, tampilannya cukup sederhana
- Konflik juga diselesaikan menggunakan SQL
Dan kekurangannya:
- Dengan beragamnya DBMS yang didukung, Oracle bukanlah salah satunya
- Tidak berinteraksi dengan ORM
- Menulis skrip T-SQL dengan tangan bukanlah tujuan kami
- Dokumentasi dan komunitasnya biasa saja, meskipun dalam hal penulisan skrip SQL mungkin tidak diperlukan.
Gedung BundarE
Alat manajemen migrasi ini, didistribusikan di bawah lisensi Apache 2.0, seperti yang sebelumnya, berjalan pada mesin migrasi T-SQL. Rupanya, para pengembang memprioritaskan penyelesaian masalah teknis terkait dukungan DBMS, daripada menciptakan proses pengembangan yang nyaman.
Pro:
- Mendukung DBMS yang diperlukan (termasuk Oracle)
Cons:
- Oracle (serta Access, yang tidak relevan bagi kami) tidak didukung di .NET Core, hanya di .NET Full Framework
- Tidak bekerja dengan ORM
- Dokumentasinya bahkan lebih sedikit dibandingkan alat sebelumnya
- Sekali lagi – migrasi ditulis dengan skrip
ThinkingHome.Migrator
Alat untuk migrasi skema database berversi ke platform .NET Core, didistribusikan di bawah lisensi MIT. .
Pro:
- Dirancang untuk .NET Inti
- Menerapkan urutan migrasi bercabang
- Pencatatan migrasi yang diterapkan
Cons:
- Terakhir diperbarui setahun yang lalu. Tampaknya proyek tersebut tidak didukung
- Tidak didukung oleh Oracle (artikel menyatakan bahwa hal ini disebabkan oleh kurangnya implementasi yang stabil untuk .NET Core - tetapi ini terjadi setahun yang lalu)
- Tidak ada pembuatan migrasi otomatis
Secara keseluruhan, proyek ini terlihat menjanjikan, terutama jika ingin dikembangkan, namun kami perlu mengambil keputusan saat ini juga.
Migrator Lancar
Alat migrasi paling populer dengan banyak penggemar. Didistribusikan di bawah lisensi Apache 2.0. Seperti yang dinyatakan dalam deskripsi, ini adalah kerangka migrasi untuk .NET, mirip dengan Migrasi Ruby on Rails. Perubahan pada skema database dijelaskan di kelas C#.
Ada keuntungan di sini:
- Dukungan untuk DBMS yang diperlukan
- Dukungan .NET Inti
- Komunitas besar yang maju
- Konflik antar migrasi diselesaikan secara berurutan—urutan pelaksanaan migrasi ditentukan. Selain itu, jika konflik muncul di sekitar satu entitas, saat menggabungkan kode, konflik tersebut diselesaikan dengan cara yang sama seperti kode lainnya.
- Ada profil yang dijalankan setelah migrasi berhasil. Dan mereka dapat menjalankan fungsi layanan.Pembaruan terakhir adalah sebulan yang lalu, artinya proyek masih berjalan
Adapun kekurangannya, ini dia:
- Tidak ada pembuatan migrasi otomatis
- Tidak ada koneksi dengan model EF
- Tidak ada snapshot database
Apa pilihan kita?
Perdebatan sengit berkisar pada dua parameter – terjadinya migrasi secara otomatis dan penyelesaian konflik yang wajar. Faktor-faktor lain tidak terlalu menakutkan. Alhasil, berdasarkan hasil diskusi, tim memutuskan untuk menggunakan Fluent Migrator pada proyek barunya. Karena menyelesaikan konflik di kemudian hari akan membawa manfaat yang jauh lebih banyak.
Temuan
Tentu saja, tidak ada alat yang sempurna. Jadi kami harus memprioritaskan “keinginan” kami untuk membuat pilihan. Namun, untuk tim lain dan tugas lain, faktor lain mungkin menentukan. Kami harap artikel ini akan membantu Anda menentukan pilihan.
Sumber: www.habr.com