Projekt bazodanowy

Jak rozwijać bazę danych w solucji

Piotr Wandycz
Narzędzia

Nie jestem fanem podejścia code-first, a migracje kojarzą mi się jedynie z migreną. Prędzej czy później zawsze pojawiał się z nimi problem, a ja bym wolał pracować bezawaryjnie i bezpiecznie. Z pomocą przychodzi SSDT (SQL Server Data Tools), dzięki któremu w prosty sposób można włączyć bazę pod kontrolę wersji, porównywać schematy baz między środowiskami, aktualizować zmiany, tworzyć nowe instancje, i tak dalej.

W starszych wersjach Visual Studio – SSDT pobierało się z Internetu. Dzisiaj wystarczy zmodyfikować VS przez instalator i upewnić się, że mamy zaznaczoną poniższą opcję:

Dodawanie projektu

Jeśli mieliśmy lub dodaliśmy SSDT, możemy dodać projekt bazodanowy do naszej solucji, w taki sam sposób jak projekt każdego innego typu. Wyszukujemy SQL Server Database Project

…podajemy nazwę…

…i możemy iść na przerwę na kawę.

Importowanie schematu

Teraz rzecz trochę ciekawsza – w jaki sposób dodać istniejącą bazę danych pod kontrolę wersji. Klikamy prawym przyciskiem myszy na nazwę projektu i importujemy go w wybrany przez siebie sposób. Chyba na konferencji SQL Day słyszałem, żeby ograniczyć się do importu przez plik *.dacpac lub opcję Database, bo ze skryptem to różnie może być. Jeśli nie mamy pod ręką wygenerowanego dacpaca, to środkowa opcja będzie najszybsza.

Naszym oczom ukaże się następujące okienko. Klikamy w Select Connection, aby wskazać, która baza ma zostać zaimportowana.

Podajemy parametry połączenia do serwera oraz wybieramy bazę, a na końcu klikamy Connect. Jeśli podaliśmy dobre dane, to wrócimy do poprzedniego okna. Wtedy wystarczy kliknąć Start.

Po krótszej lub dłuższej chwili – to zależy od wielkości bazy oraz parametrów komputera – zostaną zaimportowane wszystkie obiekty, z podziałem na schematy, jeśli posiadaliśmy coś więcej niż dbo.

Zaimportowane pliki możemy edytować, a następnie za ich pomocą zaktualizować docelową bazę. Jako że są to po prostu pliki na dysku – jeśli nasza solucja jest wpięta do kontroli wersji, nasza baza też automatycznie znajdzie się pod kontrolą wersji.

Robienie zmian

Schema Compare jest bardzo potężnym narzędziem, gdyż nie ogranicza się do porównywania bazy jedynie z tą z solucji.

Możemy wybrać dowolne miejsce jako źródło, z którego zostanie wzięty schemat, oraz cel, gdzie będziemy szukać różnic w strukturze. Nie ma znaczenia czy używamy plików z Visual Studio, czy chcemy sobie porównać od razu środowisko testowe z produkcyjnym. Po wyborze źródła i celu klikamy Compare.

Dla przykładu porównuję tu wersję bazy z lokalnej instancji SQL Servera z plikami projektu. W międzyczasie usunąłem jeden widok oraz dodałem testową tabelkę. Na każdy z tych obiektów można kliknąć i zobaczyć co dokładnie zmieniło się w strukturze. Jeśli chciałbym zastosować te zmiany na celu – klikam w Update i gotowe.

Tworzenie bazy od zera

Jeśli tworzymy nowe środowisko deweloperskie czy wdrożeniowe i musimy postawić bazę od zera – najprościej będzie skorzystać z opcji Publish.

Wybieramy połączenie do odpowiedniego serwera i wpisujemy nazwę, pod jaką chcemy utworzyć bazę i klikamy w guzik Publish.

Po chwili zobaczymy czy wszystko się udało lub jakie błędy należy poprawić.

Przedstawiłem Ci tutaj najprostsze opcje, wymagane do codziennej pracy. Z projektem bazodanowym można się jednak trochę bardziej pobawić. Jeśli mamy skrypt z początkowymi danymi, wymaganymi do funkcjonowania aplikacji, możemy utworzyć Post-Deployment Script. Dodatkowo możemy też zaznaczyć opcję generowania pliku *.sql z bazą po zbuildowaniu projektu. Ja z tego korzystam – tworząc ten plik od razu w folderze testów integracyjnych. Dzięki temu mam zawsze najnowszą wersję bazy, na której odpalane są testy. Może kiedyś to opiszę.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *