Jestem w fazie badań próbujących zaadoptować projekty baz danych na 2012 r. Na istniejącym małym projekcie. Jestem programistą C #, a nie DBA, więc nie jestem szczególnie biegły w zakresie najlepszych praktyk. Przeszukuję google i stackoverflow już od kilku godzin, ale nadal nie wiem, jak prawidłowo obsłużyć niektóre kluczowe scenariusze wdrażania.

1) W jaki sposób zarządzać wieloma wersjami mojej bazy danych w trakcie kilku cykli rozwoju? Jeśli mam klienta na v3 mojej bazy danych i chcę go uaktualnić do wersji 8, jak mam to zrobić? Obecnie zarządzamy ręcznie tworzonymi skryptami do migracji schematów i danych dla każdej wersji naszego produktu. Czy nadal musimy to robić osobno, czy jest coś w nowym paradygmacie, który to wspiera lub zastępuje?

2) Jeśli schemat zmienia się w taki sposób, że wymaga przeniesienia danych, jaki jest najlepszy sposób, aby sobie z tym poradzić? Zakładam, że niektóre prace idą w skrypcie Pre-Deployment, aby zachować dane, a następnie skrypt Post-Deploy umieszcza go z powrotem we właściwym miejscu. Czy tak jest, czy jest coś lepszego?

3) Wszelkie inne porady lub wskazówki, jak najlepiej pracować z tymi nowymi technologiami, są również bardzo mile widziane!

AKTUALIZACJA: Moje zrozumienie problemu nieco wzrosło, ponieważ początkowo zadałem to pytanie, a podczas gdy wymyśliłem praktyczne rozwiązanie, nie było to rozwiązanie, na które liczyłem. Oto przeredagowanie mojego problemu:

Problem, który mam, dotyczy wyłącznie danych. Jeśli mam klienta w wersji 1 mojej aplikacji i chcę go zaktualizować do wersji 5 mojej aplikacji, nie miałbym żadnych problemów, gdyby ich baza danych nie zawierała danych. Po prostu pozwoliłbym SSDT inteligentnie porównać schematy i migrować bazę danych jednym strzałem. Niestety klienci mają dane, więc nie jest to takie proste. Zmiany schematu z wersji 1 mojej aplikacji na wersję 2 do wersji 3 (itd.) Obejmują wszystkie dane dotyczące wpływu. Moja obecna strategia zarządzania danymi wymaga utrzymywania skryptu dla każdej aktualizacji wersji (od 1 do 2, od 2 do 3 itd.). Zapobiega to przechodzeniu od wersji 1 mojej aplikacji do wersji 5, ponieważ nie mam żadnego skryptu migracji danych, aby przejść bezpośrednio. Perspektywa tworzenia niestandardowych skryptów aktualizacji dla każdego klienta lub zarządzania skryptami uaktualnień, aby przejść z każdej wersji na każdą większą, jest wykładniczo niezarządzalna. Miałem nadzieję, że istniała strategia SSDT umożliwiająca łatwiejsze zarządzanie stroną danych, może nawet tak prosta jak strona schematu. Moje ostatnie doświadczenia z SSDT nie dały mi żadnej nadziei na taką strategię, ale chciałbym się dowiedzieć inaczej.