Kontrola wersji za pomocą SQL Server

Zaczynam nowy projekt i używam SVN (z Tortoise) jako mojego systemu kontroli wersji. Zastanawiałem się, czy możliwe jest utrzymanie bazy danych SQL Server przy użyciu tego samego systemu.

Chciałbym zaktualizować moje tabele / funkcje / widoki / procs / triggers / itp. ale nie moje dane, bo i tak będą to dane testowe. Nie jestem pewien, jak to skonfigurować. Natknąłem się na kilka opcji, ale chciałbym wiedzieć, czy czegoś brakuje, a może jest jakiś przewodnik lub coś, co pomoże mi w tym.

Widziałem i słyszałem o Czerwonej Bramie, ale szukam czegoś darmowego (lub przynajmniej bardzo taniego). Wiem, że zawsze mógłbym coś napisać, ale tak naprawdę nie staram się na to poświęcać czasu.

Jedną z rzeczy, na które się natknąłem, był pakiet open source o nazwie ScriptDB4Svn . Czy ktoś już tego używał? Czy to jest dobre? Czy może robić to, czego potrzebuję i czy konfiguracja jest dość prosta?

Technicznie nie potrzebujesz nawet narzędzia, możesz bezpośrednio skryptować obiekty i sprawdzać je pod kontrolą źródła. Bez narzędzia jest to nieco więcej pracy, ale jest to z pewnością wykonalne.

BTW: Korzystałem z narzędzia RedGate, które jest całkiem sprytne i warte swojej ceny.

Wygląda na to, że masz konfigurację głównie Microsoft. Możesz zajrzeć do projektów baz danych (wcześniej znanych jako DataDude). Zasadniczo zmieniają T-SQL w język pierwszej klasy w Visual Studio; możesz:

• Kompiluj projekty - nie tylko tworzy ostateczny skrypt, upewnia się, że istnieją nazwy obiektów itp.
• Wykonaj analizę kodu statycznego - na przykład upewniając się, że zawsze odwołujesz się do obiektów, włączając ich schemat (np. [dbo]W większości przypadków), aby uzyskać przyjemny wzrost wydajności o 30%.
• Twórz skrypty różnicowe, porównując różne wersje projektu.
• Zaktualizuj projekt z bazy danych lub skryptu (inżynier wsteczny).
• Intellisense.
• Brak narzędzi do tworzenia diagramów.

Ujednolicają Twój kod i kod bazy danych również pod kontrolą źródła. Jeśli człowiek-up i skrypt obiektów bazy danych (zamiast używania DaVinci Tools w SSMS) również wylądować przy użyciu jednego IDE - co jest miłe.

Możesz użyć szyn. Railsy mają koncepcję migracji baz danych, którą można zastosować lub wycofać. Z mojego doświadczenia wynika, że ​​jest to najlepszy sposób na aktualizację bazy danych. Sprawdzasz te pliki migracji do SVN.

W moim obecnym projekcie nie rozwijamy aplikacji w Ruby, ale nadal używamy Railsów do zarządzania bazą danych. Nie zrobiłbym tego inaczej.

Zostało to już wcześniej omówione przy stosie przepływu: /programming/2750278/sql-server-2008-create-database-script-schema-data-with-command-line

Ponadto ten artykuł zewnętrzny zawiera dodatkowe informacje http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated wraz z przykładowym kodem w postaci aplikacji systemu Windows.

Ponieważ to, co chcesz zrobić, to coś, co sam zrobiłem dla MS Access, powiem ci, co zrobiłem, na wypadek, gdyby dostarczyło ci kilku pomysłów: napisałem moduł o nazwie Ado2Xml, który konwertuje schemat i dane dowolnego ADO -dostępna baza danych do XML i odwrotnie. Wie tylko o tabelach i widokach; bez procedur składowanych, bez wyzwalaczy, bez niczego. Tak czy inaczej, w twoim przypadku moduł ten zostaje zastąpiony narzędziem, które prawdopodobnie znajdziesz, co robi, co chcesz z MS-SQL. Tak więc, przy każdym uruchomieniu mojej aplikacji porównuje znacznik czasu bazy danych z znacznikiem czasu zapisanego pliku xml; jeśli plik xml jest nowszy, to niszczy bazę danych i wywołuje Ado2Xml, aby odtworzyć go z pliku xml. Kiedy moja aplikacja się kończy, robi to w odwrotną stronę: wywołuje Ado2Xml, aby wyeksportować bazę danych do pliku xml. Tak właściwie, obiekty ADO, które wyodrębniają schemat bazy danych, są z jakiegoś powodu strasznie powolne, przez co proces eksportowania zajmuje trochę czasu. Aby uniknąć konieczności każdorazowego oczekiwania na zakończenie działania aplikacji, a Visual Studio przełączy się z układu debugowania na układ edycji, tuż przed jego zakończeniem, moja aplikacja uruchamia zewnętrzną aplikację w celu wykonania eksportu, aby mogła zakończyć działanie natychmiast.

Tak, użyłem podobnego narzędzia (opracowanego wewnętrznie) w poprzednim projekcie. Skryptowałby wszystkie tabele, widoki, sproki, wyzwalacze itp. W osobnych plikach .sql. Następnie mieliśmy skrypt uruchamiany co noc, aby „sprawdzić”, czy wszystko w naszej „rozwojowej” bazie danych zostało odzwierciedlone w kontroli źródła.

Więc normalny przepływ pracy polega na tym, że zmieniłbyś kod, zmienił odpowiednie tabele i sproki w bazie danych programowania zgodnie z wymaganiami, a następnie uruchomiłbyś nasze narzędzie, które odświeżyłoby wszystkie skrypty .sql. Następnie sprawdziłeś wszystko na raz.

Problem polegał na tym, że jeśli zapomnisz uruchomić narzędzie, kod „zadziała” (a testy jednostkowe przejdą), ponieważ baza danych jest „poprawna”, ale nowe sproki / tabele nie będą kontrolować źródła.

Każdej nocy mamy skrypt, który sprawdzał kod źródłowy, a następnie rand narzędzia, aby odświeżyć wszystkie skrypty. Jeśli była jakaś różnica, oznacza to, że ktoś zapomniał sprawdzić ich zmiany i wygenerowano powiadomienie e-mail. Był to po prostu sposób na upewnienie się, że nie zapomnieliśmy aktualizować kontroli źródła.

Było to trochę denerwujące, ponieważ utrudniało pracę nad zmianami obejmującymi wiele dni, ale było lepsze niż brak ...