Mengapa dan kapan Liquibase?


99

Saya telah mencari jawaban ini di stack overflow, tetapi saya tidak dapat menemukan pertanyaan tentang ini. Saya baru Liquibasedan ingin belajar

  • Kenapa Liquibase?
  • Kapan tepatnya harus digunakan Liquibasedalam proyek ini?

Saya tahu bahwa ini untuk menyimpan semua perubahan database di satu tempat tetapi hal serupa dapat dilakukan dengan membuat SQLfile sederhana di beberapa sistem repositori dan terus memperbaruinya seiring waktu.

Jawaban:


70

Pembeda utama antara file pembuatan skema yang dikelola sendiri dan Liquibase (atau alat migrasi skema lainnya ) adalah bahwa yang terakhir menyediakan log perubahan skema. Ini adalah catatan perubahan skema dari waktu ke waktu. Ini memungkinkan perancang database untuk menentukan perubahan dalam skema & mengaktifkan peningkatan atau penurunan terprogram skema sesuai permintaan.

Manfaat lainnya, seperti:

  • Independensi vendor database (ini dipertanyakan, tetapi mereka mencoba)
  • dokumentasi otomatis
  • perbedaan skema database

Salah satu alat alternatif adalah jalur terbang .

Anda akan memilih untuk menggunakan alat migrasi skema saat Anda ingin atau perlu mengelola pembaruan skema secara otomatis tanpa kehilangan data. Artinya, Anda mengharapkan skema berubah setelah sistem Anda diterapkan ke lingkungan yang tahan lama seperti situs pelanggan atau lingkungan pengujian yang stabil.


1
Tapi misalkan kita membuat file dan menulis skrip pertama kita di dalamnya dan mengkomitnya menjadi git. Sekarang, seiring berjalannya waktu, skema akan diperbarui dan kita dapat kembali ke interval waktu mana pun dan juga mengubah skema, bukan?
Shakeel Shahzad

1
Dengan pendekatan itu, Anda dapat membuat ulang skema, tetapi Anda tidak dapat menurunkan versi / meningkatkan. Perbedaannya adalah hilangnya data.
Synesso

1
Tetapi bagian lain, kapan harus digunakan hilang?
Shakeel Shahzad

1
Synesso Saya belum melihat bagaimana Anda dapat menurunkan versi database produksi secara otomatis setelah digunakan untuk sementara waktu dan keputusan telah dibuat pada data menggunakan, katakanlah kolom yang baru ditambahkan. Anda tidak bisa begitu saja menjatuhkannya sekarang. Juga saya tidak melihat mengapa ini lebih baik dari sekedar serangkaian skrip SQL berversi yang disimpan dalam kontrol sumber yang mencakup penyisipan sederhana ke dalam tabel versi di awal dan pembaruan untuk itu di akhir untuk melacak apa yang telah diterapkan.
Khorkrak

Pertanyaan lain menambahkan ... bagaimana kita bisa mencatat kesalahan melalui email di java. kapan perubahan SQL berubah melalui XML?
UmaShankar

18

Saya telah melihat liquibase menciptakan disiplin di antara para pengembang dalam hal memodifikasi skema. Anda tidak bisa pergi dan menimpa perubahan dan eksekusi pengembang lain. Sebaliknya, Anda membuat kumpulan perubahan Anda sendiri dan menambahkannya ke akhir urutan perubahan yang akan dieksekusi. Hal ini juga memberikan kejelasan tentang perubahan apa yang terjadi, kapan dan siapa yang membawanya.

Pendekatan yang sangat "berversi" untuk pemeliharaan skema.

Sebagai permulaan, itu memang memberi kesan "pekerjaan yang tidak perlu".


4
Yang mana saya (Ini memberi saya kesan yang tepat yang Anda sebutkan: P) +1 untuk tekad penting itu
Ismail Sahin

Anda benar, kami dapat melacak semua perubahan yang membuat perubahan terbaru dan kapan. jika kita perlu mengulang kembali ke titik tertentu, likuibase akan membantu
Anoop PS

7

Ketika Anda memiliki beberapa contoh database di dev, qa, produksi dan Anda ingin memiliki alat untuk secara otomatis melacak riwayat perubahan dan menerapkan perubahan secara cerdas (menerapkan perbedaan skema saat ini dan skema akhir), alat seperti liquibase atau flyway akan sangat berguna .


3

Saya percaya Liquibase sangat bagus ketika filosofi Anda adalah bahwa database adalah renungan. Filosofi ini telah menyebabkan sebagian besar database buruk dalam produksi - dan kebanyakan dari mereka buruk. Basis data harus dirancang dengan tampilan penuh dari keseluruhan sistem bisnis, tidak dibuat oleh pengembang aplikasi yang masing-masing bekerja di silo mereka sendiri. Metode terakhir menghasilkan penyelesaian, data yang tidak normal, hubungan yang buruk antar tabel, duplikasi area bisnis, dan keseluruhan sistem dengan biaya perawatan tinggi yang berantakan yang akan dibenci klien segera setelah penerapan karena masalah yang ditimbulkannya. Jika database dirancang untuk SECARA AKURAT mencerminkan hubungan bisnis, umurnya akan 5 kali lebih lama dan akan memenuhi tujuannya 5 kali lebih baik daripada database yang dirancang secara sepotong-sepotong seperti yang sayangnya kebanyakan.

Liquibase bukanlah masalah itu sendiri tetapi memungkinkan praktik pengembang aplikasi merancang database. Itulah masalahnya.


19
Spesifikasi berubah, fitur baru ditambahkan, bug diperbaiki. Bahkan dengan asumsi "database dirancang untuk SECARA AKURAT mencerminkan hubungan bisnis", itu normal dan diharapkan bahwa Anda perlu membuat perubahan pada DB dari waktu ke waktu, karena bisnis dan hubungan bisnis berubah seiring waktu. Liquibase hanya membantu Anda mengelola perubahan tersebut. Itu dia.
Steven Byks

Dalam pengalaman saya, sangat sedikit DBA dan sejumlah besar pengembang menggunakan Liquibase - saya pikir @ bob-barry tepat dengan sebagian besar hasil akhir. DBA yang menggunakan alat seperti Liquibase (atau sekadar git lama untuk riwayat perubahan) akan merasa berguna.
PhillipHolmes

Praktik DB evolusioner, dan gesit secara umum, mendorong dan mengaktifkan tinjauan sejawat. Untuk DB dengan kebutuhan kinerja, DBA masih bekerja dengan tim aplikasi untuk perubahan DB. Alat seperti Liquibase memungkinkan pemfaktoran ulang lebih mudah, bertentangan dengan argumen denormalisasi Anda. 10 tahun yang lalu, saya bekerja untuk produk yang dipasang di 20+ klien, masing-masing dengan siklus tambalan dan peningkatan mereka sendiri. Setelah 2 tahun mengalami mimpi buruk, dan mencoba menulis alat tersebut dengan tangan, kami beralih ke liquibase segera setelah kami mempelajarinya. Dan kami memiliki tabel dengan 200 M record, tidak terlalu besar untuk saat itu, tapi sesuatu yang membutuhkan DBA.
pengguna6317694

3
Saya berharap untuk bertemu Anda di sana di surga suatu hari nanti. Kedengarannya bagus.
Bijan

3

Saya pikir Mengapa liquibase dapat dijawab jika Anda membaca artikel di bawah ini http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html

Jika Anda membacanya dengan hati-hati, kemampuan untuk menurunkan versi ke versi yang lebih rendah dari versi yang lebih tinggi dengan bantuan perintah mvn atau CLI sederhana sangat berguna yang tidak Anda dapatkan jika Anda melakukan pendekatan untuk memasukkan file sql Anda ke GIT karena kemudian Anda harus menjalankan skrip tersebut secara manual dan juga Anda tidak memiliki set perubahan seperti: - siapa yang membuat penulis perubahan, dll.


0

Menjadi DevOps Person dari tim saya, saya lebih suka memiliki semua file SQL saya di satu tempat yaitu Di SCM (Manajemen Kode Sumber) saya

Juga selama fase CI / CD, Jika Skema DB dibuat bersama dengannya, Ini menghemat banyak waktu dan sumber daya. Anda tidak perlu meminta orang lain mengelola database Anda untuk klien itu.

ORM seperti Flyway, Liquibase, EF, dll. Membantu dalam mencapai hal ini.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.