Migrasi Skema: Alat Data SQL Server vs Liquibase dan Flyway


11

Ini mungkin tampak seperti pertanyaan bodoh, tetapi saya telah mencari solusi open source untuk migrasi skema, yaitu Liquibase dan Flyway.

Namun, bos saya memberi tahu saya bahwa SQL Server Data Tools (SSDT) ​​mencapai pekerjaan yang sama. Saya tidak yakin apakah setuju, tetapi saya dapat menemukan sangat sedikit di Internet yang secara langsung membandingkannya dengan Liquibase dan / atau Flyway.

Pandangan saya adalah bahwa SSDT adalah alat pengembangan, pemodelan data dan desain untuk SQL Server dan juga mendukung perbandingan skema (dan menghasilkan skripnya) dan kontrol sumber. Ini menangani masalah yang berbeda walaupun mungkin ada beberapa tumpang tindih dengan Liquibase / Flyway dalam beberapa aspek migrasi skema. Tetapi sebagai alat migrasi skema keseluruhan, Liquibase dan Flyway adalah alat yang sepenuhnya berdedikasi sedangkan SSDT lebih untuk desain dan pengembangan database.

Pendapat apa pun akan sangat dihargai bahkan jika itu hanya untuk mengatakan tidak ada perbandingan dan SSDT sama sekali bukan alat migrasi skema.

Jawaban:


17

SSDT dapat dibandingkan dengan Liquibase / Flyway karena melakukan apa yang mereka lakukan tetapi dengan mengambil pendekatan yang berbeda. Dengan SSDT Anda memiliki lingkungan pengembangan sehingga Anda mendapatkan hal-hal seperti pergi ke definisi, menemukan referensi dan akal budi serta kemampuan untuk mengkompilasi proyek menjadi dacpac dan kemudian menggunakan dacpac itu ke database.

Cara SSDT (dan redgate sql membandingkan cara) untuk melakukan deloyment adalah dengan menyatakan apa yang Anda inginkan jadi jika Anda ingin mengubah tabel yang terlihat seperti:

create table a(id int)

ke tabel yang terlihat seperti:

create table a(id int, another_column varchar(12))

dengan SSDT Anda cukup mengubah definisi tabel Anda menjadi yang kedua dan membiarkan SSDT khawatir tentang cara memutakhirkannya (dapatkah itu mengubah tabel, menambah kolom, atau melakukan perubahan urutan kolom sehingga Anda perlu membangun kembali tabel, dll).

Dengan Liquibase (DbUp, ReadyRoll, metode manual, dll.) Yang Anda lakukan dalam hal ini harus menulis sendiri tabel alter dan pastikan Anda menjalankan skrip dalam urutan yang benar, pertimbangkan skenario ini:

  1. Rilis 1 - buat kolom halo di atas meja
  2. Rilis 2 - ganti nama kolom halo menjadi joe_blogs
  3. Rilis 3 - ganti nama kolom joe_blogs menjadi halo
  4. Rilis 4 - buat kolom joe_blogs

Jika ada rilis yang terlewatkan, tidak ada yang berikutnya yang dapat dilanjutkan.

Manfaat skrip pemutakhiran (Liquibase, DbUp, dll):

  • Anda memiliki kontrol penuh atas skrip
  • DBA / Pengembang terbiasa dengan ini

Manfaat membandingkan / menggabungkan (SSDT, Redgate SQL Bandingkan):

  • Tidak perlu menulis skrip pemutakhiran
  • Sangat mudah untuk mendapatkan versi spesifik mana saja dengan hanya membandingkan dan menggabungkan versi itu

Kerugian dari skrip upgrade:

  • Harus dijalankan secara berurutan
  • Mengandalkan manusia tidak membuat kesalahan
  • Bisa lambat terutama jika Anda memiliki banyak perubahan
  • Kecuali jika tim Anda adalah basis data yang sangat disiplin dalam lingkungan yang berbeda (pengembang, pengujian, pementasan, dll) sering menjadi tidak sinkron sehingga pengujian apa pun tidak valid
  • Menurunkan versi rilis berarti menulis kebalikan dari semua skrip yang telah Anda tulis

Kerugian menggunakan membandingkan / menggabungkan:

  • Alat tidak 100% tepercaya, mungkin tidak adil
  • SSDT memerlukan proyek yang berfungsi, banyak banyak basis data yang memiliki kode yang tidak benar-benar dikompilasi atau dijalankan (bayangkan tabel yang dijatuhkan tetapi bukan prosedur dll), saya telah melihat ini di sekitar 8/10 basis data yang telah saya warisi :)
  • Banyak DBA / pengembang ragu untuk menyerah mengembangkan SSMS / notepad

Secara pribadi saya benar-benar berpikir SSDT adalah lingkungan pengembangan profesional dan itu berarti bahwa saya dapat berkonsentrasi pada penulisan kode dan tes yang berguna daripada menulis skrip upgrade yang dengan sendirinya hanya sarana untuk mencapai tujuan.

Anda meminta pendapat jadi begini :)

ed


1
Apakah SSDT berfungsi dengan hal lain selain SQL Server? mis. Postgres?
a_horse_with_no_name

3
Tidak ada "alat data server SQL" :)
Ed Elliott

1
Kenapa tidak? Paket SSIS dapat mentransfer sebagian besar semua sumber ODBC
a_vlad

Kecuali saya salah paham, saya pikir kita berbicara tentang mengelola skema database daripada membuat paket ssis? Senang dikoreksi :)
Ed Elliott

1
SSIS dimaksudkan untuk memindahkan data dan karenanya mendukung koneksi ke berbagai macam sistem. SSDT dimaksudkan untuk pengembangan dan pemeliharaan proyek database SQL Server. Ini memiliki proses pembuatan yang memeriksa versi SQL Server yang ditargetkan untuk kompatibilitas skrip dan memeriksa semua referensi, procs, dll. Untuk sintaks T-SQL.
Dave

2

Saya hanya isi ulang jawaban previsi.

Perbedaan terbesar dijelaskan pada situs web Flyway di tempat sentral:

Memecahkan hanya satu masalah dan menyelesaikannya dengan baik. Flyway memigrasi basis data Anda, jadi Anda tidak perlu khawatir lagi.

Visual Studio + SSDT + SSIS = Alat ETL daya penuh, dengan hanya satu kelemahan nyata - ini hanya bekerja di bawah windows. Perlu Windows + SQL Server untuk menjalankan paket, tetapi bekerja dengan sebagian besar semua sumber.

Untuk mentransfer / memigrasikan data - banyak produk di pasar. Komersial, Sumber Terbuka, Komunitas / Ekspres dan lain-lain

Untuk kode migrasi - semua tidak begitu baik. Bahkan jika perangkat lunak menjanjikan "konversi pemicu, prosedur, dan fungsi tanpa masalah", pada kenyataannya - hanya sederhana, kebanyakan migrasi kode - manual.


2

Saya telah bekerja dengan kedua alat data server Sql dan jalur terbang. Menggunakan SSDT, saya mendapatkan keuntungan berikut:

  1. Saya dapat mengkompilasi proyek database .. artinya, tidak ada rasa takut menjatuhkan kolom yang direferensikan oleh tampilan, fungsi atau procs yang disimpan. Ini adalah fitur yang hebat, karena di masa lalu, kami menemukan tentang kehilangan seperti itu hanya setelah rilis
  2. Setelah berhasil membangun, SSDT menghasilkan apa yang dikenal sebagai "DACPAC". Pikirkan ini MSI dengan versi.

  3. Dacpac yang diberikan, dengan mengatakan versi 5, dapat diterapkan ke basis data yang ada di Dacpac versi 1,2,3,4 atau 6,7,8 dll. Jika diterapkan pada 1-4, basis data akan ditingkatkan. Jika diterapkan pada 6,7 ​​dll, DB akan diturunkan / diputar kembali. Akan ada peringatan, jika akan ada kehilangan data, yang bisa ditekan. Jadi, kami mendapatkan fitur rollback yang hebat, yang tidak tersedia dengan alat lain seperti jalur terbang dll. Dengan jalur terbang, kita harus menyediakan satu set skrip baru untuk memutar kembali.

  4. DACPAC menerapkan semua perubahan dalam satu transaksi; artinya jika ada 5 perubahan tabel dalam upgrade dan salah satunya gagal, seluruh transaksi dibatalkan. Flyway juga mendukung ini, tetapi untuk setiap file.

Namun, SSDT dan DACPAC adalah Microsoft SQL Server khusus; jalur terbang dapat digunakan untuk berbagai database.

Jadi, intinya, jika Anda hanya menggunakan SQL Server, itu harus menjadi keputusan yang cukup mudah untuk pergi dengan SSDT dan DACPACs.

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.