Perbandingan dan pemilihan sistem migrasi data
Model data cenderung berubah semasa proses pembangunan, dan pada satu ketika ia tidak lagi sepadan dengan pangkalan data. Sudah tentu, pangkalan data boleh dipadamkan, dan kemudian ORM akan mencipta versi baharu yang akan sepadan dengan model, tetapi prosedur ini akan menyebabkan kehilangan data sedia ada. Oleh itu, fungsi sistem migrasi adalah untuk memastikan bahawa, akibat daripada perubahan skema, ia disegerakkan dengan model data dalam aplikasi tanpa kehilangan data sedia ada.
Dalam artikel ini, kami ingin melihat pelbagai alat untuk menguruskan migrasi pangkalan data. Kami berharap ulasan ini berguna untuk pembangun yang menghadapi pilihan yang sama.
Petugas
Syarikat kami sedang giat membangunkan generasi produk seterusnya β Docs Security Suite (DSS). Bahagian pelayan ditulis dalam Teras Bersih, dan Teras Rangka Kerja Entiti digunakan sebagai DBMS. Apabila mereka bentuk aplikasi, kami menggunakan pendekatan Kod Pertama.
Model domain aplikasi dicipta oleh beberapa pembangun pada masa yang sama - masing-masing bertanggungjawab untuk bahagian logik sistem mereka sendiri.
DSS generasi sebelumnya menggunakan Migrasi Rangka Kerja Entiti klasik (EF 6) sebagai sistem pengurusan migrasi. Walau bagaimanapun, beberapa aduan telah terkumpul terhadapnya, yang utama ialah EF tidak mempunyai pendekatan yang waras untuk menyelesaikan konflik versi. Fakta ini masih mengganggu kami apabila membetulkan pepijat sebagai sebahagian daripada sokongan, jadi kami memutuskan untuk mempertimbangkan pilihan alternatif.
Hasil daripada perbincangan, keperluan berikut untuk sistem pengurusan migrasi telah dibentuk:
- Sokongan untuk pelbagai DBMS. MS SQL Server, PostgreSQL, Oracle diperlukan, tetapi ia berpotensi untuk menggunakan orang lain
- Bekerja dengan ORM. Pada mulanya, ia dirancang untuk menggunakan EF Core, tetapi pada peringkat reka bentuk kami bersedia untuk mempertimbangkan ORM lain
- Penjanaan automatik migrasi. Mengambil kira pembangunan Kod Pertama, saya ingin mengelakkan keperluan untuk "tulis tangan" migrasi
- Konflik versi. Dalam persekitaran pembangunan teragih, apabila bergabung, EF Core boleh mengalami konflik. Ini menjadi masalah penting kerana bahagian aplikasi yang berbeza dicipta oleh pembangun yang berbeza, jadi anda perlu menghabiskan banyak masa pada setiap
- Dokumentasi dan sokongan lanjutan. Di sini, nampaknya kami, tiada penjelasan diperlukan
- Percuma. Kriteria adalah bersyarat, kerana sistem tidak terlalu mahal atau mahal, tetapi sesuai untuk kemudahan, kami juga bersedia untuk mempertimbangkan
Hasil daripada sedikit penyelidikan, pilihan berikut ditemui dan didapati wajar untuk dipertimbangkan:
- Migrasi Teras EF
- DBup
- Rumah bulatE
- ThinkingHome.Migrator
- Penghijrah yang Fasih
Dan kini lebih terperinci
Sememangnya, ini adalah pilihan pertama dan utama untuk dipilih. Alat muzik asli yang berfungsi di luar kotak tanpa bermain-main dengan rebana. Sejumlah besar dokumentasi, rasmi dan tidak begitu, kesederhanaan, dsb. Walau bagaimanapun, aduan yang dibuat tentang EF klasik juga agak relevan untuk Teras EF.
Oleh itu, kelebihan untuk Teras EF diserlahkan:
- Sokongan Microsoft, dokumentasi, termasuk dalam bahasa Rusia, komuniti besar
- Penjanaan automatik migrasi berdasarkan CodeFirst
- Berbanding dengan EF 6, EF Core tidak lagi menyimpan petikan pangkalan data. Apabila bekerja dengan EF Core dalam Code First, anda tidak perlu menggunakan pangkalan data lagi
- Memandangkan kami menari dari Code First, adalah mungkin untuk menjalankan satu migrasi ke semua penyedia akses data yang diperlukan
- Mengenai pembekal, PostgreSQL disokong, Oracle disokong, dsb., dsb., dan juga MS SQL Server ο
Dan juga keburukan:
- Penyelesaian konflik kekal pada tahap yang sama. Ia adalah perlu untuk menyusun migrasi dan mengemas kini petikan pangkalan data
- Kebergantungan pada model yang mana migrasi dijana
DbUp
DbUp ialah perpustakaan .NET yang dipasang oleh NuGet dan membantu menolak perubahan pada SQL Server. Ia menjejaki skrip perubahan mana yang telah dilaksanakan dan menjalankan skrip yang diperlukan untuk mengemas kini pangkalan data. Perpustakaan ini berkembang daripada projek untuk enjin blog sumber terbuka pada ASP.NET dan wujud di bawah lesen MIT, dan kod itu ada pada GitHub. Migrasi diterangkan menggunakan T-SQL.
Apakah kelebihannya:
- Sokongan untuk sejumlah besar DBMS (MS SQL Server, PstgreSQL, MySQL)
- Oleh kerana skrip ditulis dalam T-SQL, ia kelihatan agak mudah
- Konflik juga diselesaikan menggunakan SQL
Dan keburukan:
- Dengan semua jenis DBMS yang disokong, Oracle bukanlah salah satu daripadanya
- Tidak berinteraksi dengan ORM
- Menulis skrip T-SQL dengan tangan bukanlah apa yang kami sasarkan
- Dokumentasi dan komuniti adalah begitu-begitu, walaupun dari segi menulis skrip SQL mereka mungkin tidak diperlukan.
Rumah bulatE
Alat pengurusan migrasi ini, diedarkan di bawah lesen Apache 2.0, seperti yang sebelumnya, berjalan pada enjin migrasi T-SQL. Nampaknya, pembangun mengutamakan menyelesaikan masalah teknikal berkenaan sokongan DBMS, dan bukannya mencipta proses pembangunan yang selesa.
Kelebihan:
- Menyokong DBMS yang diperlukan (termasuk Oracle)
Cons:
- Oracle (serta Access, yang tidak relevan untuk kami) tidak disokong pada Teras .NET, hanya pada Rangka Kerja Penuh .NET
- Tidak berfungsi dengan ORM
- Terdapat lebih sedikit dokumentasi daripada alat sebelumnya
- Sekali lagi - migrasi ditulis oleh skrip
ThinkingHome.Migrator
Alat untuk pemindahan skema pangkalan data versi ke platform Teras .NET, diedarkan di bawah lesen MIT. .
Kelebihan:
- Direka untuk .NET Core
- Melaksanakan urutan percabangan migrasi
- Pembalakan migrasi yang dilaksanakan
Cons:
- Terakhir dikemas kini setahun yang lalu. Nampaknya projek itu tidak disokong
- Tidak disokong oleh Oracle (artikel menyatakan bahawa ini disebabkan oleh kekurangan pelaksanaan yang stabil untuk .NET Core - tetapi ini setahun yang lalu)
- Tiada penjanaan migrasi automatik
Secara keseluruhan, projek itu kelihatan menjanjikan, terutamanya jika ia akan dibangunkan, tetapi kami perlu membuat keputusan di sini dan sekarang.
Penghijrah yang Fasih
Alat penghijrahan yang paling popular dengan ramai peminat. Diedarkan di bawah lesen Apache 2.0. Seperti yang dinyatakan dalam huraian, ia adalah rangka kerja migrasi untuk .NET, serupa dengan Ruby on Rails Migrations. Perubahan pada skema pangkalan data diterangkan dalam kelas C#.
Terdapat kelebihan di sini:
- Sokongan untuk DBMS yang diperlukan
- Sokongan Teras .NET
- Masyarakat maju yang besar
- Konflik antara migrasi diselesaikan secara berurutanβurutan pelaksanaan migrasi ditentukan. Di samping itu, jika konflik timbul di sekitar satu entiti, apabila menggabungkan kod, ia diselesaikan dengan cara yang sama seperti dalam kod yang lain.
- Terdapat profil yang dilaksanakan selepas penghijrahan berjaya. Dan mereka boleh membawa fungsi perkhidmatan. Kemas kini terakhir adalah sebulan yang lalu, iaitu, projek itu masih hidup
Bagi minus, berikut adalah:
- Tiada penjanaan migrasi automatik
- Tiada sambungan dengan model EF
- Tiada petikan pangkalan data
Apakah pilihan kita?
Perdebatan hangat berkisar pada dua parameter - penjanaan penghijrahan automatik dan penyelesaian konflik yang waras. Faktor lain adalah kurang menakutkan. Hasilnya, berdasarkan hasil perbincangan, pasukan memutuskan untuk menggunakan Fluent Migrator dalam projek baharu. Kerana menyelesaikan konflik pada masa hadapan akan membawa lebih banyak faedah.
Penemuan
Sudah tentu, tidak ada alat yang sempurna. Jadi kami terpaksa mengutamakan "kehendak" kami untuk membuat pilihan. Walau bagaimanapun, untuk pasukan lain dan tugas lain, faktor lain mungkin menjadi penentu. Kami berharap artikel ini akan membantu anda membuat pilihan.
Sumber: www.habr.com