Visual Studio z SQL Server Data Tools (SSDT)

SQL Server Data Tools to rozszerzenie Visual Studio umożliwiające projektowanie baz danych i pakietów SSIS.

Rola SSDT w środowisku Visual Studio

SQL Server Data Tools (SSDT) to zestaw narzędzi zintegrowanych z Visual Studio, przeznaczony do pracy z rozwiązaniami opartymi na Microsoft SQL Server. Rozszerzenie pozwala tworzyć projekty baz danych, analizować skrypty T-SQL, porównywać schemat projektu ze schematem istniejącej bazy oraz przygotowywać wdrożenia zmian. Projekt bazy przechowuje definicje obiektów, takich jak tabele, kolumny, klucze, indeksy, widoki, procedury składowane, funkcje, wyzwalacze i uprawnienia. Dzięki temu schemat może być traktowany jako kod źródłowy i przechowywany w systemie kontroli wersji.

SSDT korzysta z mechanizmu analizy kodu właściwego dla projektów SQL. Podczas kompilacji narzędzie sprawdza składnię oraz zależności między obiektami, na przykład odwołanie widoku do tabeli albo procedury do innej procedury. Pozwala to wykryć część problemów jeszcze przed połączeniem z docelową bazą. Nie jest to jednak pełny test działania aplikacji ani gwarancja poprawności danych. Projekt może zostać zbudowany poprawnie, mimo że zapytanie będzie nieefektywne, zwróci nieoczekiwane wyniki albo będzie wymagało określonych danych testowych.

Projekt bazy danych jako artefakt wdrożeniowy

W projekcie SSDT definicje obiektów są zwykle rozdzielone na pliki odpowiadające elementom schematu. Po zbudowaniu projektu powstaje pakiet DACPAC, czyli plik zawierający model docelowej bazy danych. DACPAC nie jest kopią danych produkcyjnych. Opisuje strukturę oraz właściwości obiektów, które mają znaleźć się w bazie. Może być wykorzystany do utworzenia nowej bazy albo do porównania modelu projektu z istniejącą bazą SQL Server.

Podczas publikowania SSDT wylicza różnice między modelem zapisanym w DACPAC a schematem wskazanej bazy. Na tej podstawie generowany jest skrypt zmian, obejmujący między innymi utworzenie nowych tabel, modyfikację kolumn, zmianę indeksów lub aktualizację procedur. Przed wykonaniem takiego skryptu należy sprawdzić jego wpływ na dane i zależności. Zmiana typu kolumny, usunięcie obiektu albo przebudowa klucza może wymagać migracji danych, dodatkowego skryptu albo ręcznej decyzji administratora. Ustawienia publikowania pozwalają między innymi kontrolować operacje destrukcyjne, lecz nie zastępują kopii zapasowej i testu na środowisku nieprodukcyjnym.

W rozwiązaniach Visual Studio projekt bazy może współistnieć z kodem aplikacji oraz testami. Ułatwia to powiązanie wersji procedur składowanych i schematu z konkretną wersją programu. SSDT może także służyć do generowania skryptów wdrożeniowych używanych później przez narzędzia automatyzacji. W takim modelu kompilacja projektu tworzy powtarzalny artefakt, a publikowanie jest osobnym etapem, wykonywanym po zatwierdzeniu parametrów połączenia i zakresu zmian.

SSIS i pozostałe typy projektów danych

W ekosystemie SSDT dostępne są również narzędzia do projektowania pakietów SQL Server Integration Services (SSIS). Pakiet SSIS jest przepływem zadań i transformacji służącym do pobierania, przekształcania oraz zapisywania danych. W Visual Studio można układać przepływ danych z komponentów, definiować połączenia do źródeł i miejsc docelowych, ustalać mapowanie kolumn oraz dodawać obsługę błędnych rekordów. Oddzielny przepływ sterowania określa kolejność wykonywania zadań, warunki przejścia i reakcję na powodzenie lub błąd.

Pakiety SSIS mogą zawierać parametry, zmienne, wyrażenia oraz menedżery połączeń. Ich konfiguracja powinna być rozdzielona od samego projektu, aby ten sam pakiet można było uruchamiać na różnych środowiskach z innymi serwerami, bazami lub katalogami plików. Przy projektowaniu należy uwzględnić typy danych, kodowanie tekstu, wartości puste, konwersje oraz zachowanie przy powtórnym uruchomieniu. Sam fakt poprawnego zapisania pakietu w Visual Studio nie potwierdza, że import wykona się poprawnie na dużym zbiorze danych lub po zmianie struktury źródła.

W zależności od zainstalowanych składników i zgodności z używaną wersją SQL Server, SSDT może obsługiwać także projekty związane z innymi usługami analitycznymi Microsoft. Dostępne szablony oraz wymagane rozszerzenia zależą od wersji Visual Studio i komponentów zainstalowanych w systemie. Przy otwieraniu starszego rozwiązania trzeba sprawdzić zgodność projektu, wersję docelową serwera oraz obecność wymaganych dodatków, ponieważ sama instalacja Visual Studio nie musi zawierać wszystkich narzędzi SSDT.

Sprawdzanie instalacji i diagnozowanie problemów z projektem

Problemy z SSDT często wynikają z niezgodności wersji Visual Studio, brakującego rozszerzenia albo wybranego niewłaściwego typu projektu. W pierwszej kolejności warto sprawdzić, czy projekt bazy lub SSIS jest rozpoznawany przez środowisko, czy w Eksploratorze rozwiązań są dostępne właściwe szablony oraz czy kompilacja wskazuje konkretny plik i obiekt powodujący błąd. Należy również zweryfikować ustawioną platformę docelową SQL Server i porównać ją z możliwościami serwera, na którym projekt ma zostać wdrożony.

W przypadku projektu bazy pomocne jest wygenerowanie skryptu publikowania bez wykonywania go na serwerze. Taki skrypt można przejrzeć pod kątem usuwania obiektów, zmian kolumn, blokad oraz operacji wymagających zachowania istniejących danych. Błędy odwołań mogą pojawić się, gdy projekt nie zawiera wymaganej tabeli, gdy obiekt znajduje się w innej bazie albo gdy brakuje odwołania do projektu lub odpowiedniego pliku referencyjnego. W SSIS trzeba dodatkowo sprawdzić dostawców połączeń, uprawnienia konta uruchamiającego pakiet, wersję komponentów oraz zgodność typów danych między źródłem i miejscem docelowym.

Na komputerze używanym do pracy deweloperskiej warto utrzymywać zgodny zestaw Visual Studio, SSDT i wymaganych rozszerzeń, a rozwiązania otwierać po utworzeniu kopii repozytorium lub gałęzi roboczej. Jeżeli błąd dotyczy wyłącznie jednego stanowiska, należy porównać zainstalowane składniki, wersje rozszerzeń i ustawienia projektu z konfiguracją pozostałych komputerów. Przy problemach z budowaniem lub publikowaniem potrzebne są konkretne komunikaty z okna błędów oraz logi procesu, ponieważ ogólny komunikat o nieudanym wdrożeniu nie wskazuje, czy przyczyną jest składnia, zależność, połączenie czy konflikt schematu.