Jak korzystać z projektu bazy danych SQL Server

Question

Używam programu SQL Server 2012 i VS 2010 z zainstalowanym SSDT (SQL Server Data Tools). Mój dev DB używa zapisanych proców, funkcji, obiektów CLR itp. Ma migawkę danych prod około 500GB.

Utworzono projekt bazy danych SQL Server, a następnie zaimportowałem bazę danych. Spowoduje to utworzenie wszystkich tabel, widoków, procesów i plików funkcji pod nazwami schematów. Świetne rzeczy - teraz mogę zrobić kontrolę wersji, tak jak w innych projektach VS, tworzyć wdrożenia itp. Jak dotąd, tak dobrze.

Ale, nie jestem zdezorientowany co do tego, jaki powinien być mój proces rozwoju dla zmiany/dodawania proców/tabel w ramach projektu bazy danych SQL Server. Wygląda na to, że wszelkie zmiany, które wprowadzam, są stosowane do niektórych baz danych LocalDb/Projects, a NIE do mojej bazy danych dev.

Czy mam utworzyć wszystkie moje obiekty w tym LocalDb, a następnie zbudować i wdrożyć do mojej bazy danych dev poprzez publikację? Martwię się o moje istniejące tabele w bazie danych deweloperów, ponieważ jeśli proces publikowania spadnie i ponownie utworzy tabele, stracę swoją migawkę danych prod.

Jaka jest właściwa procedura programowania do zastosowania w projekcie bazy danych SQL Server?

Answer 1

1. Wprowadź zmiany w projekcie DB VS.

2. Wdrażanie zmian localDB przetestować

3. Publikowanie bazy danych na serwerze produkcyjnym. Wolę używać Schema Compare, aby zrobić to ręcznie, ale możesz również opublikować projekt za pomocą prawego przycisku myszy -> menu publikowania (który również utworzy profil publikowania) lub używając argumentów wiersza poleceń. Proces publikowania nie zostanie upuszczony i nie utworzy tabel (chyba, że ​​powiesz mu, aby zrezygnował z odtworzenia całego DB).

Alternatywnie, w ustawieniach projektu można zmienić ciąg połączenia tak, aby wskazywał na serwer produkcyjny (jak wskazano w komentarzu). Jednak zalecam od tego, ponieważ będzie on próbował publikować na serwerze produkcyjnym za każdym razem, gdy uruchomisz lokalną kompilację (F5).

Answer 2

Pomyśl o źródłowej bazie danych (w twoim przypadku, projekcie bazy danych) jako o stanie "być" po wdrożeniu. Po rozpoczęciu wdrażania plik wykonywalny (SqlPackage.exe) porównuje źródło z celem i generuje skrypt różnicowy/delta, aby cel wyglądał jak źródło. Dlatego nie musimy już określać CREATE ani ALTER; narzędzie to wyodrębnia. Aby odpowiedzieć na twoje pytanie dotyczące stałego rozwoju, możesz rozwijać się w dowolny sposób. Możesz rozwijać się w plikach projektu i publikować je we wspólnej bazie danych Dev (powiedzmy, jeśli jesteś w zespole), lub możesz rozwijać w bazie danych narzędzia takie jak SQL Server Management Studio (SSMS) i synchronizować z plikami projektu z porównaniem schematu (używam tej ostatniej techniki, ponieważ lubię SSMS).

Do wdrożenia konieczne będzie zainstalowanie SSDT na komputerze, z którego uruchamiane jest wdrożenie (dyski SSDT są dostarczane z programem SQL Server 2012 i nowszym, nie wiem o programie SQL Server 2008). Możesz tworzyć skrypty, aby uprościć wdrażanie. Zasadniczo wywołasz SqlPackage.exe (w X: \ Program Files (x86) \ Microsoft SQL Server \ nnn \ DAC \ bin) z akcją i źródłem. Używam również Opublikuj profile, aby zadbać o większość właściwości polecenia.Więc przykładem wdrażania może wyglądać następująco:

SqlPackage.exe /Action:Publish /SourceFile:MyDatabase.dacpac /Profile:MyProfile.publish.xml 

Aby uzyskać więcej informacji: SQL Server Data Tools Documentation http://msdn.microsoft.com/en-us/library/hh272686(v=vs.103).aspx

SqlPackage.exe Documentation http://msdn.microsoft.com/en-us/library/hh550080(v=vs.103).aspx