Kontrola wersji za pomocą SQL Server

14

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?

Yannis
źródło
1
Has anyone used this before? Is it good? Can it do the things I need it to do and is it pretty simple to get setup?Dlaczego boisz się spróbować sam? Po prostu złap go i baw się.
yannis
@YannisRizos - na pewno to zrobię, jeśli nie otrzymam zbyt dużej odpowiedzi, po prostu chciałem zaoszczędzić trochę czasu i zobaczyć, czy ktoś wcześniej z tym pracował, czy też ktoś próbował i przetestował od razu które pasują do moich potrzeb, dzięki czemu mogę zaoszczędzić trochę czasu na eksperymentach.
Właśnie zauważyłem, jak nowy jesteś tutaj. Programiści SE nie są dobrym miejscem do zadawania pytań, aby zaoszczędzić trochę czasu, naprawdę oczekujemy, że zrobisz coś takiego dla siebie, tj. Wykonasz własne badania przed zapytaniem . Lub, alternatywnie, zapytaj na czacie (ale nie oczekuj solidnych odpowiedzi). Powiedziawszy to, to naprawdę nie ma znaczenia, ponieważ to ostatnie zdanie nie jest twoim głównym pytaniem, które jest w rzeczywistości bardzo dobre (i właściwie oznaczone, rzadkie dla nowych użytkowników, kudos!).
yannis
@YannisRizos - dzięki. Wskoczę na czat, aby sprawdzić, czy mogę uzyskać informacje zwrotne dotyczące ScriptDB4Svn, i sprawdzę tutaj, czy są dostępne aktualizacje podstawowego pytania. Edycja: Wygląda na to, że nie mogę czatować, dopóki nie mam 20 powtórzeń. No cóż, chyba cierpliwość.

Odpowiedzi:

2

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.

JohnFx
źródło
Więc w zasadzie zrobiłbym swoją pracę w Management Studio, a następnie wyeksportowałem skrypty do katalogu SVN i po prostu robiłem to za każdym razem, gdy nad nim pracowałem (zastępując stare przy każdym eksporcie)? Myślę, że to zadziała. Zachowałoby to funkcjonalność SVN umożliwiającą przywracanie i takie tam, ale tak, byłoby to trochę kłopotliwe. Może sprawdzę ceny RedGate i zobaczę, czy warto.
@Scott - Ręczny sposób może działać, musisz tylko inaczej myśleć o swoim rozwoju SQL. Skrypty są obiektami „oficjalnymi”, a wersja SQL jest tylko skompilowaną wersją. Podobnie jak kod źródłowy.
JohnFx,
Postanowiłem zrobić rzeczy ręcznie i prawdopodobnie zaimplementować skrypt za pomocą pomocy w linkach podanych przez Mike'a Nakisa, ale na razie zamierzam użyć wbudowanego GUI w Management Studio do wyeksportowania skryptów tworzenia DB, kiedy skończę działa, sprawdź te i pozwól, aby SVN utrzymywał je w ten sposób. Ponieważ zdecydowałem się robić rzeczy ręcznie, otrzymujesz odpowiedź na wskazanie, że tak naprawdę nie potrzebuję narzędzia do robienia takich rzeczy :)
1

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.

Jonathan Dickinson
źródło
0

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.

Vinnie
źródło
Czy są jakieś przewodniki, które wyjaśnią to nieco bardziej i zaczną przygotowywać coś takiego?
Właściwie to nie jest zbyt dobry pomysł na używanie Railsów razem z technologiami .NET.
alternatywnie
Rozdział dotyczący migracji Railsów ( guide.rubyonrails.org/migrations.html ). To powinno wystarczyć, aby zacząć i dać ci wszystkie potrzebne informacje, dlaczego jest to dobry pomysł. @altern - ponieważ używasz Railsów do manipulowania i wersjonowania bazy danych, powinno to mieć jakikolwiek wpływ na technologie i .NET. Możesz uzyskać dostęp do bazy danych i korzystać z niej w taki sam sposób, jakbyś nie korzystał z szyn. Nie miałbym nic przeciwko zobaczeniu odniesień do twoich obaw. Czy IronRuby nie jest implementacją Ruby and Rails w .Net?
Vinnie,
> Czy IronRuby nie jest implementacją Ruby and Rails w .Net? IronRuby to implementacja Ruby w .NET . Nie jestem pewien, czy Railsy działają poprawnie na IronRuby. Mój ogólny argument przeciwko używaniu Railsów w celu wersjonowania db jest taki, że Ruby i powiązane technologie (RoR, migratinos) mają dość stromą krzywą uczenia się, szczególnie w przypadku tak prostych zadań, jak wersjonowanie db. Można go używać do innych celów, nie tylko do migracji. W przeciwnym razie zwiększy to złożoność projektu bez większego pozytywnego efektu.
alternatywnie
0

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.

Mike Nakis
źródło
Dwa podane linki są prawdopodobnie czymś, czym osobiście jestem zainteresowany, więc mogę w zasadzie zautomatyzować ręczne kroki, które teraz wykonuję. Dzięki za te!
0

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 ...

Dean Harding
źródło
Czy możesz opracować dalej Then, we had a script that ran every night to "validate" that everything in our "development" database was reflected in source control.? Dzięki za twoją odpowiedź.
@Scott: Zredagowałem odpowiedź, aby podać nieco więcej szczegółów.
Dean Harding