Şema Geçişi: SQL Server Veri Araçları ve Liquibase ve Flyway

Bu aptalca bir soru gibi görünebilir, ancak şema göçü için Liquibase ve Flyway için açık kaynak çözümlerini araştırıyorum.

Ancak, patronum bana SQL Server Veri Araçları'nın (SSDT) ​​aynı işi başardığını söyledi. Kabul edip etmediğinizden emin değilim, ancak internette Liquibase ve / veya Flyway ile doğrudan karşılaştıran çok az şey bulabilirim.

Benim görüşüme göre SSDT SQL Server için bir geliştirme, veri modelleme ve tasarım aracıdır ve ayrıca şema karşılaştırmasını (ve komut dosyalarını oluşturmayı) ve kaynak kontrolünü destekler. Şema göçünün bazı yönlerinde Liquibase / Flyway ile bazı çakışmalar olabilse de, farklı bir problemle uğraşır. Ancak genel bir şema geçiş aracı olarak Liquibase ve Flyway tamamen özel araçlardır, ancak SSDT bir veritabanının tasarımı ve geliştirilmesi için daha fazladır.

Sadece karşılaştırma yapılmadığını ve SSDT'nin kendi başına bir şema taşıma aracı olmadığını söylese bile, herhangi bir görüş çok takdir edilecektir.

SSDT, Liquibase / Flyway ile yaptıkları gibi farklı bir yaklaşımla karşılaştırılabilir. SSDT ile geliştirme ortamına sahip olursunuz, böylece tanımlamaya gitmek, referanslar ve zekâ bulmak ve bir projeyi bir dacpac'a derleme ve daha sonra bu dacpac'ı bir veritabanına dağıtma gibi şeyler elde edersiniz.

Bir deloyment işlemi yapmanın SSDT yolu (ve redgate sql karşılaştırma yolu), aşağıdaki gibi bir tabloyu değiştirmek istiyorsanız, ne istediğinizi bildirmektir:

create table a(id int)

şuna benzer bir tabloya:

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

SSDT ile sadece tablo tanımınızı ikincisine değiştirirsiniz ve SSDT'nin nasıl yükseltileceği konusunda endişelenmesine izin verirsiniz (tabloyu değiştirebilir, sütun ekleyebilir veya sütun sırası değişikliği yapabilir, böylece tabloyu yeniden oluşturmanız gerekir).

Liquibase (DbUp, ReadyRoll, manuel yöntemler vb.) İle yaptığınız şey bu durumda alter tablosunu kendiniz yazmak ve komut dosyalarını doğru sırada çalıştırdığınızdan emin olmaktır, bu senaryoyu göz önünde bulundurun:

1. Sürüm 1 - Tabloda sütun merhaba oluşturun
2. Sürüm 2 - Merhaba sütunu joe_blogs olarak yeniden adlandırın
3. Sürüm 3 - joe_blogs sütununu merhaba olarak yeniden adlandır
4. Sürüm 4 - joe_blogs sütunu oluştur

Sürümlerden herhangi biri kaçırılırsa, bir sonraki sürümlerin hiçbiri devam edemez.

Yükseltme komut dosyalarının (Liquibase, DbUp, vb.) Faydaları:

• Senaryolar üzerinde tam kontrole sahipsiniz
• DBA'lar / Geliştiriciler buna alışkındır

Karşılaştırma / birleştirme avantajları (SSDT, Redgate SQL Compare):

• Yükseltme komut dosyaları yazmak zorunda değilsiniz
• Herhangi bir belirli sürüme ulaşmak kolaydır, sadece bu sürümü karşılaştırın ve birleştirin

Yükseltme komut dosyalarının sakıncaları:

• Sırayla çalıştırılmalıdır
• Hata yapmayan insanlara güvenin
• Özellikle çok fazla değişikliğiniz varsa yavaş olabilir
• Ekibiniz farklı ortamlardaki (dis, test, sahneleme, prod vb.) Çok disiplinli veritabanları olmadığı sürece, genellikle herhangi bir testi geçersiz kılan senkronizasyon dışı hale gelir
• Bir sürümü düşürmek, daha önce yazmış olduğunuz tüm komut dosyalarının tersini yazmak anlamına gelir

Karşılaştırma / birleştirme kullanmanın sakıncaları:

• Araçlar% 100 güvenilir değil, belki de haksız
• SSDT çalışan bir proje gerektirir, birçok veritabanı aslında derlemeyen veya çalışmayan kodlara sahiptir (bırakılan tabloları düşünün, ancak prosedürleri vb. Düşünmeyin), bunu miras aldığım yaklaşık 8/10 veritabanında gördüm :)
• Birçok DBA / geliştirici SSMS / not defteri geliştirmeden vazgeçmekte tereddüt ediyor

Şahsen ben SSDT'nin profesyonel bir gelişim ortamı olduğunu düşünüyorum ve bu sadece kendi için bir araç olan yükseltme komut dosyaları yazmak yerine yararlı kod ve testler yazmaya konsantre olabileceğim anlamına geliyor.

Fikirler istediniz, işte gidiyorsunuz :)

ed

Öncelikli cevabı tamamlıyorum.

Merkezi yerde Flyway web sitesinde açıklanan en büyük fark:

Sadece bir problemi çözer ve iyi çözer. Flyway veritabanınızı geçirir, böylece artık endişelenmenize gerek kalmaz.

Visual Studio + SSDT + SSIS = tam güç ETL Aracı, tek bir gerçek dezavantajı ile - sadece pencereler altında çalışır Bu paketleri çalıştırmak için Windows + SQL Server gerekir, ancak çoğunlukla tüm kaynaklarla çalışır.

Verileri aktarmak / taşımak için - piyasadaki birçok ürün. Ticari, Açık Kaynaklar, Topluluk / Ekspres vb.

Göç kodu için - hepsi çok iyi değil. Yazılım "tetikleyicileri, prosedürleri ve fonksiyonları sorunsuz bir şekilde dönüştür" sözünü vermiş olsa bile, aslında - sadece basit, çoğu kod geçişi - manuel.

Sql sunucusu veri araçları ve flyway ile çalıştım. SSDT kullanarak, aşağıdaki avantajları elde ederim:

1. Ben veritabanı projesi derleyebilir .. yani, bir görünüm, fonksiyon veya saklı procs tarafından başvurulan bir sütun bırakma korkusu yoktur. Bu harika bir özellik, çünkü geçmişte, bu tür kayıpları sadece sürümden sonra bulduk

2. Başarılı bir derlemeden sonra, SSDT "DACPAC" olarak bilinen şeyi üretir. Bunu bir sürümü olan bir MSI düşünün.

3. Belirli bir dacpac, örneğin sürüm 5 ile, Dacpac sürüm 1,2,3,4 veya 6,7,8 vb. Üzerindeki bir veritabanına uygulanabilir. 1-4'e uygulanırsa, veritabanı yükseltilir. 6,7 vb. Yöntemlere uygulanırsa, DB indirgenir / geri alınır. Bastırılabilecek veri kaybı olacaksa uyarılar olacaktır. Bu nedenle, flyway vb. Gibi diğer araçlarla birlikte bulunmayan harika bir geri alma özelliği elde ediyoruz.

4. DACPAC tüm değişiklikleri tek bir işlemde uygular; yani yükseltme işleminde 5 tablo değişikliği varsa ve bunlardan biri başarısız olursa, işlemin tamamı geri alınır. Flyway de bunu destekliyor, ancak her dosya için.

Ancak, SSDT ve DACPAC'lar Microsoft SQL Server'a özgüdür; flyway çeşitli veritabanları için kullanılabilir.

Sonuç olarak, sadece SQL Server kullanıyorsanız, SSDT ve DACPAC'lerle gitmek oldukça kolay bir karar olmalıdır.