Od samego początku zastanawiałem się, jak ustrukturyzować odpowiedź na to pytanie. Jest to trudne, ponieważ w przypadku VS2010 nie chodzi o opis funkcji i zalet tego narzędzia. Chodzi o przekonanie czytelnika, aby dokonał zasadniczej zmiany w podejściu do tworzenia baz danych. Niełatwe.
Odpowiedzi na to pytanie udzielają doświadczeni specjaliści z baz danych, z mieszanką w tle obejmującą DBA, programistę / dba oraz OLTP i hurtownię danych. Nie jest dla mnie opłacalne podejście do każdego aspektu rozwoju bazy danych za jednym posiedzeniem, więc postaram się uzasadnić konkretny scenariusz.
Jeśli twój projekt spełnia te kryteria, uważam, że istnieje przekonujący argument za VS2010:
- Twój zespół używa VS2010 do tworzenia aplikacji.
- Twój zespół używa TFS do kontroli źródła i zarządzania kompilacją.
- Twoja baza danych to SQL Server.
- Twój zespół ma już lub jest zainteresowany automatycznymi testami VS.
Jeśli oceniasz VS2010 pod kątem rozwoju bazy danych, twoją biblią będzie Visual Studio Database Guide z Visual Studio ALM Rangers . Wszelkie cytaty, które nie zawierają odnośników, będą pochodzić z tego dokumentu.
Idziemy więc ...
Dlaczego proces tworzenia bazy danych różni się od tworzenia aplikacji?
Dane. Gdyby nie te nieznośne dane, tworzenie baz danych byłoby uciążliwe. Możemy po prostu ZROBIĆ wszystko na każdym wydaniu i zapomnieć o tym kłopotliwym zarządzaniu zmianami.
Istnienie danych komplikuje proces zmiany bazy danych, ponieważ dane są często migrowane, przekształcane lub ponownie ładowane, gdy zmiany są wprowadzane przez działania programistyczne, które wpływają na kształt tabel bazy danych lub innych schematów danych. W trakcie tego procesu zmian dane dotyczące jakości produkcji i stan operacyjny muszą być chronione przed zmianami, które mogą zagrozić jego integralności, wartości i przydatności dla organizacji.
Co jest nie tak z SSMS?
Z jakiegoś powodu nazywa się to SQL Server Management Studio. Jako samodzielne narzędzie niepraktyczne jest zarządzanie działaniami programistycznymi, jeśli zamierzasz przestrzegać przyjętych najlepszych praktyk.
W przypadku samych skryptów, aby w sposób znaczący zastosować ustalone praktyki kontroli źródła w twoim rozwoju, będziesz musiał zachować obie definicje obiektów (np. Skrypt CREATE TABLE) ORAZ zmieniać skrypty (np. ALTER TABLE) ORAZ ciężko pracować, aby upewnić się, że pozostają zsynchronizowane.
Łańcuch wersji zmian w tabeli dość szybko staje się głupi. Bardzo uproszczony przykład:
-- Version 1
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20))
-- Version 2
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(50))
-- Version 3
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(100))
W wersji 3 skrypt zmiany bazy danych zawiera:
ALTER TABLE dbo.Widget ADD Description VARCHAR(50)
ALTER TABLE dbo.Widget ALTER COLUMN Description VARCHAR(100)
Jeśli wersja na żywo tej bazy danych to wersja 1, a nasza następna wersja to wersja 3, poniższy skrypt byłby wszystkim, czego potrzeba, ale zamiast tego zostaną wykonane obie instrukcje ALTER.
ALTER TABLE dbo.Widget ADD Description VARCHAR(100)
5-letnie 4-tygodniowe sprinty składają się na zabawne skrypty wersji i wymagają dodatkowej obsługi, aby zminimalizować wpływ na czas wdrażania.
Czy coś jest nie tak z SSMS? Nie, nadaje się do tego, do czego służy, administrowania programem SQL Server i zarządzania nim. Nie udaje nawet, że pomaga deweloperowi bazy danych w (czasami) bardzo złożonym zadaniu zarządzania zmianą.
Jeśli nie możesz zbudować każdej wersji bazy danych ze źródła i uaktualnić do dowolnej przyszłej wersji, kontrola źródła jest zepsuta. Jeśli tak nie uważasz, zapytaj Erica Sink .
Co z SSMS + <- wstaw narzędzie do porównywania schematów ->?
Jest to zdecydowanie krok we właściwym kierunku i pochłania wiele ręcznego wysiłku wymaganego do obsługi skryptów. Ale (i to duży, ale), zwykle są to ręczne kroki.
Popularne narzędzia do porównywania schematów można w pełni zautomatyzować i zintegrować z procesem kompilacji. Jednak z mojego doświadczenia wynika, że bardziej powszechną praktyką jest ręczne uruchamianie porównania, a wynikowe skrypty są wypatrywane, sprawdzane w kontroli źródła, a następnie uruchamiane ręcznie w celu wdrożenia. Niedobrze.
Ilekroć my omylni ludzie musimy angażować się w proces budowania lub wdrażania, wprowadzamy ryzyko i sprawiamy, że proces ten nie jest powtarzalny.
Jeśli ty i twój zespół jesteście jednymi z nielicznych, którzy mają w pełni zautomatyzowane porównywanie i wdrażanie schematów, czapki z głów! Jesteście najbardziej otwarci na korzyści, jakie VS2010 ma do zaoferowania:
- Już zaakceptowałeś, że ręczne kroki są niebezpieczne.
- Widzisz wartość automatyzacji.
- Jesteś gotów zainwestować czas niezbędny do jego działania.
Jeśli nie można utworzyć kompilacji w jednym kroku lub wdrożyć w jednym kroku, proces programowania i wdrażania jest zepsuty. Jeśli tak nie uważasz, zapytaj Joela Spolsky'ego .
Dlaczego VS2010?
Pytanie postawione przez @NickChammas dotyczy funkcji zabójczych, które pokazują, dlaczego VS2010 jest zmieniaczem gier do tworzenia baz danych. Nie sądzę, żebym mógł to zrobić na tej podstawie.
Być może komicznie, gdy inni widzą wady tego narzędzia, widzę silne powody do przyjęcia:
- Będziesz musiał zmienić swoje podejście.
- Ty i twój zespół będziecie zmuszeni do pracy w inny sposób.
- Będziesz musiał szczegółowo ocenić wpływ każdej zmiany.
- Zostaniesz poprowadzony do uczynienia każdej zmiany idempotentną .
Jeśli jesteś jedynym DBA w projekcie, zarządzającym wszystkimi zmianami w bazie danych, to rozumowanie musi brzmieć absurdalnie. Jeśli jednak uważasz, że @BrentOzar ma rację i jedną z nowych zasad jest to, że Wszyscy są DBA , będziesz musiał kontrolować zmianę bazy danych w sposób, z którym każdy programista w zespole może współpracować.
Przyjęcie projektów baz danych może wymagać zmiany mentalnej ( stare nawyki są trudne do złamania ) dla niektórych programistów lub przynajmniej zmiany w procesie lub przepływach pracy. Programiści, którzy opracowali aplikacje bazodanowe, w
których produkcyjna baza danych reprezentuje bieżącą wersję bazy danych, będą musieli przyjąć podejście oparte na kodzie źródłowym, w którym kod źródłowy staje się narzędziem, w którym wprowadzane są zmiany w bazach danych . W projektach bazy danych Visual Studio projekt i kod źródłowy to „Jedna wersja prawdy” dla schematu bazy danych i jest zarządzany za pomocą przepływów pracy SCM, które prawdopodobnie są już używane przez programistę lub organizację do innych części stosu aplikacji. W przypadku danych produkcyjna baza danych pozostaje „jedną wersją prawdy” taką, jaka powinna być.
Doszliśmy do fundamentalnej zmiany, która jest niezbędna do pomyślnego przyjęcia podejścia VS2010 do tworzenia baz danych…
Traktuj swoją bazę danych jako kod
Nigdy więcej zmiany bazy danych na żywo. Każda zmiana bazy danych będzie przebiegać według tego samego wzoru co zmiana aplikacji. Modyfikuj źródło, kompiluj, wdrażaj. To nie jest tymczasowa zmiana kierunku od Microsoft, to przyszłość dla SQL Server . Baza danych jako kod jest już dostępna.
Twórca bazy danych określa kształt obiektu dla wersji aplikacji, a nie sposób mutowania istniejącego obiektu w silniku bazy danych do pożądanego kształtu. Być może zastanawiasz się: w jaki sposób można to wdrożyć w bazie danych, która już zawiera tabelę klientów? Tutaj właśnie pojawia się silnik wdrażania. Jak wspomniano wcześniej, aparat wdrażania weźmie skompilowaną wersję schematu i porówna ją z celem wdrożenia bazy danych. Mechanizm różnicowania wygeneruje niezbędne skrypty do zaktualizowania docelowego schematu, aby pasował do wersji wdrażanej z projektu.
Tak, istnieją inne narzędzia, które działają w podobny sposób, a dla projektów poza ograniczeniami, które nałożyłem na moją odpowiedź, są one warte równego rozważenia. Ale jeśli pracujesz z programem Visual Studio i Team Foundation Server ALM, nie sądzę, aby mogli konkurować.
Co jest nie tak z projektami baz danych VS2010?
- Nie są idealne . Ale jeśli znasz ograniczenia i obszary problemowe, możesz je obejść.
- Złożone ruchy danych nadal wymagają opieki i uwagi, ale są pokrywane za pomocą skryptów wdrażania przed / po.
Edycja: Więc o co ci chodzi?
@AndrewBickerton wspomniał w komentarzu, że nie odpowiedziałem na pierwotne pytanie, dlatego postaram się podsumować „Dlaczego powinienem używać Visual Studio 2010 przez SSMS do tworzenia baz danych?” tutaj.
- SSMS nie jest narzędziem do tworzenia baz danych. Tak, możesz rozwijać TSQL za pomocą SSMS, ale nie zapewnia on bogatych funkcji IDE VS2010.
- VS2010 zapewnia platformę do traktowania bazy danych jako kodu.
- VS2010 wprowadza analizę kodu statycznego do kodu bazy danych.
- VS2010 zapewnia narzędzia do pełnej automatyzacji cyklu kompilacji-wdrożenia-testu.
- SQL2012 i Visual Studio vNext rozszerzają możliwości projektów baz danych. Zapoznaj się teraz z VS2010, a uzyskasz przewagę nad narzędziami do tworzenia baz danych nowej generacji.