Migracja schematu: SQL Server Data Tools vs. Liquibase i Flyway

To może wydawać się głupim pytaniem, ale szukałem rozwiązań open source do migracji schematów, mianowicie Liquibase i Flyway.

Jednak mój szef powiedział mi, że SQL Server Data Tools (SSDT) ​​wykonuje to samo zadanie. Nie jestem pewien, czy się zgadzam, ale niewiele mogę znaleźć w Internecie, który bezpośrednio porównuje go do Liquibase i / lub Flyway.

Moim zdaniem SSDT jest narzędziem do programowania, modelowania i projektowania danych dla SQL Server, a także obsługuje porównywanie schematów (i generowanie ich skryptów) oraz kontrolę źródła. Zajmuje się innym problemem, chociaż niektóre aspekty migracji schematu mogą się pokrywać z Liquibase / Flyway. Ale jako ogólne narzędzie do migracji schematów, Liquibase i Flyway są w pełni dedykowanymi narzędziami, podczas gdy SSDT służy raczej do projektowania i rozwoju bazy danych.

Wszelkie opinie byłyby mile widziane, nawet jeśli tylko powiedzieć, że nie ma porównania, a SSDT nie jest narzędziem do migracji schematu w ogóle.

SSDT jest porównywalny z Liquibase / Flyway, ponieważ robi to, co robi, ale stosując inne podejście. Dzięki SSDT masz środowisko programistyczne, dzięki czemu możesz przejść do definicji, znaleźć referencje i inteligencję, a także możliwość kompilacji projektu w dacpac, a następnie wdrożyć ten dacpac w bazie danych.

Sposobem SSDT (i sposobem porównywania redgate sql) jest zadeklarowanie tego, co chcesz, więc jeśli chcesz zmienić tabelę, która wygląda:

create table a(id int)

do stołu, który wygląda jak:

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

z SSDT po prostu zmieniasz definicję tabeli na drugą i pozwalasz SSDT martwić się o to, jak ją uaktualnić (czy może zrobić zmianę tabeli, dodać kolumnę lub zmienić kolejność kolumn, więc będziesz musiał odbudować tabelę itp.).

W przypadku Liquibase (DbUp, ReadyRoll, metody ręczne itp.) W tym przypadku musisz samodzielnie napisać tabelę zmian i upewnić się, że uruchamiasz skrypty we właściwej kolejności, rozważ ten scenariusz:

1. Wersja 1 - utwórz kolumnę witaj na stole
2. Wersja 2 - zmień nazwę kolumny hello na joe_blogs
3. Wersja 3 - zmień nazwę kolumny joe_blogs na witaj
4. Wersja 4 - utwórz kolumnę joe_blogs

Jeśli któreś z wydań zostanie pominięte, żadne z następnych nie będzie kontynuowane.

Korzyści ze skryptów aktualizacji (Liquibase, DbUp itp.):

• Masz pełną kontrolę nad skryptami
• DBA / Developerzy są do tego przyzwyczajeni

Korzyści z porównania / scalenia (SSDT, Redgate SQL Compare):

• Nie musisz pisać skryptów aktualizacji
• Łatwo jest przejść do dowolnej konkretnej wersji, wystarczy ją porównać i połączyć

Wady skryptów aktualizacji:

• Musi być uruchamiany w kolejności
• Polegaj na ludziach, którzy nie popełniają błędów
• Może być powolny, szczególnie jeśli masz wiele zmian
• O ile Twój zespół nie jest bardzo zdyscyplinowany, bazy danych w różnych środowiskach (programowanie, testowanie, przemieszczanie, prod itp.) Często nie są zsynchronizowane, co powoduje nieprawidłowe testowanie
• Obniżenie wersji oznacza napisanie na odwrót wszystkich skryptów, które już napisałeś

Wady używania porównania / scalania:

• Narzędzia nie są w 100% zaufane, być może niesprawiedliwe
• SSDT wymaga działającego projektu, wiele baz danych ma kod, który tak naprawdę nie kompiluje się ani nie uruchamia (myślę, że usunięte tabele, ale nie procedury itp.), Widziałem to w około 8/10 bazach danych, które odziedziczyłem :)
• Wielu programistów / programistów DBA nie chce zrezygnować z programowania w SSMS / notatniku

Osobiście uważam, że SSDT jest profesjonalnym środowiskiem programistycznym i oznacza, że ​​mogę skoncentrować się na pisaniu przydatnego kodu i testów zamiast na pisaniu skryptów aktualizacyjnych, które same w sobie są jedynie środkiem do celu.

Prosiłeś o opinie, więc proszę :)

wyd

Po prostu doładowuję odpowiedź dotyczącą podglądu.

Największa różnica opisana na stronie internetowej Flyway w centralnym miejscu:

Rozwiązuje tylko jeden problem i rozwiązuje go dobrze. Flyway migruje twoją bazę danych, więc nie musisz się już o to martwić.

Visual Studio + SSDT + SSIS = narzędzie ETL o pełnej mocy, z tylko jedną prawdziwą wadą - działa tylko w systemie Windows Potrzebuje systemu Windows + SQL Server do uruchamiania pakietów, ale działa głównie ze wszystkimi źródłami.

Do przesyłania / migracji danych - wiele produktów na rynku. Komercyjne, otwarte źródła, społeczność / ekspresowe itp

W przypadku migracji kodu - wszystko nie jest tak dobre. Nawet jeśli oprogramowanie obiecuje „konwersję wyzwalaczy, procedur i funkcji bez problemów”, w rzeczywistości - tylko prosta, większość migracji kodu - ręczna.

Pracowałem zarówno z narzędziami do danych serwera Sql, jak i flyway. Korzystając z SSDT, mam następujące zalety:

1. Mogę skompilować projekt bazy danych .. co oznacza, że ​​nie ma obaw o upuszczenie kolumny, do której odwołuje się widok, funkcja lub przechowywane procy. To świetna funkcja, ponieważ w przeszłości o takich brakach dowiedzieliśmy się dopiero po wydaniu

2. Po pomyślnej kompilacji SSDT generuje tak zwany „DACPAC”. Pomyśl o tym MSI z wersją.

3. Dany dacpac, powiedzmy wersja 5, może być zastosowany do bazy danych, która znajduje się w wersji Dacpac 1,2,3,4 lub 6,7,8 itd. Jeśli zostanie zastosowany do 1-4, baza danych zostanie zaktualizowana. W przypadku zastosowania do 6,7 itd. DB zostanie obniżone / wycofane. Pojawią się ostrzeżenia, jeśli nastąpi utrata danych, które można stłumić. Otrzymujemy więc świetną funkcję wycofywania, która nie jest dostępna w przypadku innych narzędzi, takich jak flyway itp. W flyway trzeba udostępnić nowy zestaw skryptów do wycofania.

4. DACPAC stosuje wszystkie zmiany w jednej transakcji; co oznacza, że ​​w przypadku aktualizacji 5 zmian tabeli i jedna z nich się nie powiedzie, cała transakcja zostanie wycofana. Flyway również to obsługuje, ale dla każdego pliku.

Jednak SSDT i DACPAC są specyficzne dla Microsoft SQL Server; flyway może być używany do różnych baz danych.

Podsumowując, jeśli używasz tylko programu SQL Server, wybór SSDT i DACPAC powinien być dość łatwą decyzją.