Wersjonowanie bazy danych SQL Server


315

Chcę przejąć kontrolę nad moimi bazami danych. Czy ktoś ma jakieś porady lub polecane artykuły na początek?

Zawsze będę chciał mieć tam jakieś dane (jak wspomina alumb : typy użytkowników i administratorzy). Często też chcę dużej kolekcji wygenerowanych danych testowych do pomiarów wydajności.


Zobacz także białą księgę; Ostateczny przewodnik po kontroli wersji bazy danych www3.dbmaestro.com/…
DBAstep

Odpowiedzi:


179

Martin Fowler napisał mój ulubiony artykuł na ten temat, http://martinfowler.com/articles/evodb.html . I nie zdecyduje się umieścić schemat zrzuca się pod kontrolą wersji jako alumb i inni sugerują, bo chcą w łatwy sposób zaktualizować bazę produkcyjną.

W przypadku aplikacji internetowej, w której będę mieć jedną produkcyjną instancję bazy danych, używam dwóch technik:

Skrypty aktualizacji bazy danych

Skrypty aktualizacji bazy danych sekwencji zawierające DDL niezbędne do przeniesienia schematu z wersji N do N + 1. (Te są w twoim systemie kontroli wersji.) Tabela _version_history_, coś w rodzaju

create table VersionHistory (
    Version int primary key,
    UpgradeStart datetime not null,
    UpgradeEnd datetime
    );

otrzymuje nowy wpis przy każdym uruchomieniu skryptu aktualizacji, który odpowiada nowej wersji.

Dzięki temu można łatwo sprawdzić, która wersja schematu bazy danych istnieje, a skrypty aktualizacji bazy danych są uruchamiane tylko raz. Ponownie, nieto zrzuty bazy danych. Każdy skrypt reprezentuje raczej zmiany niezbędne do przejścia z jednej wersji do drugiej. Są to skrypty stosowane do produkcyjnej bazy danych w celu jej „uaktualnienia”.

Synchronizacja piaskownicy programisty

  1. Skrypt do tworzenia kopii zapasowych, czyszczenia i zmniejszania produkcyjnej bazy danych. Uruchom to po każdej aktualizacji do produkcyjnej bazy danych.
  2. Skrypt do przywracania (i poprawiania, jeśli to konieczne) kopii zapasowej na stacji roboczej programisty. Każdy programista uruchamia ten skrypt po każdej aktualizacji do produkcyjnej bazy danych.

Ostrzeżenie: moje zautomatyzowane testy działają na bazie poprawnej schematu, ale pustej bazie danych, więc ta rada nie będzie idealnie odpowiadać twoim potrzebom.


16
Skrypty kontroli pełnego schematu wersji są bardzo przydatne w celach informacyjnych. Na przykład nie można zobaczyć, co dokładnie zostało zmienione w procedurze przechowywanej, patrząc na instrukcję ALTER PROCEDURE.
Constantin

12
Zrzut (i wersjonowanie) pełnego schematu bazy danych po uruchomieniu nowych skryptów aktualizacji jest dobrym sposobem na udostępnienie informacji innym narzędziom również w procesie kompilacji / wdrażania. Ponadto posiadanie pełnego schematu w skrypcie oznacza możliwość „wypompowania” świeżej bazy danych bez wykonywania wszystkich kroków migracji. Umożliwia także różnicowanie bieżącej wersji z poprzednimi wersjami.
mlibby

2
Czy mówisz, że umieścisz skrypty aktualizacji w kontroli źródła, nie wprowadzasz tam skryptów wycofywania?
AK

9
Mam zwyczaj utrzymywania pełnego skryptu tworzenia i upuszczania, a także skryptów delta do aktualizowania istniejących instancji db. Oba przechodzą do kontroli wersji. Skrypty delta są nazywane zgodnie z numerami wersji. W ten sposób można łatwo zautomatyzować łatanie bazy danych za pomocą skryptu aktualizacji.
nikc.org

1
Odpowiedź @ nikc.org oraz haczyki po zatwierdzeniu do automatyzacji.
Silviu-Marian,

45

Produkt SQL Gate firmy Red Gate nie tylko pozwala na porównywanie na poziomie obiektu i generowanie skryptów zmian z tego, ale także pozwala eksportować obiekty bazy danych do hierarchii folderów uporządkowanej według typu obiektu, z jednym utworzeniem [nazwa obiektu] .sql skrypt na obiekt w tych katalogach. Hierarchia typów obiektów wygląda następująco:

\ Functions
\ Security
\ Security \ Roles
\ Security \ Schemas
\ Security \ Users
\ Stored Procedures
\ Tables

Jeśli po wprowadzeniu zmian zrzucisz skrypty do tego samego katalogu głównego, możesz użyć tego do zaktualizowania repozytorium SVN i zachować osobną historię każdego obiektu.


6
Właśnie wypuściliśmy SQL Source Control, który integruje opisane przez ciebie zachowanie SQL Compare z SSMS oraz linki do SVN i TFS. Do tego pytania dodałem osobną odpowiedź, która bardziej szczegółowo opisuje jego działanie. red-gate.com/products/SQL_Source_Control/index.htm
David Atkinson

39

Jest to jeden z „trudnych problemów” związanych z rozwojem. O ile mi wiadomo, nie ma idealnych rozwiązań.

Jeśli potrzebujesz tylko przechowywać strukturę bazy danych, a nie dane, możesz wyeksportować bazę danych jako zapytania SQL. (w Enterprise Manager: kliknij prawym przyciskiem myszy bazę danych -> Wygeneruj skrypt SQL. Zalecam ustawienie „Utwórz jeden plik na obiekt” na karcie opcji). Następnie możesz zatwierdzić te pliki tekstowe do svn i skorzystać z funkcji różnicowania i logowania svn.

Mam to powiązane ze skryptem Batch, który pobiera kilka parametrów i konfiguruje bazę danych. Dodałem również dodatkowe zapytania, które wprowadzają domyślne dane, takie jak typy użytkowników i użytkownik admin. (Jeśli chcesz uzyskać więcej informacji na ten temat, opublikuj coś, a ja mogę umieścić skrypt w dostępnym miejscu)

Jeśli chcesz zachować wszystkie dane, zalecamy wykonanie kopii zapasowej bazy danych i skorzystanie z produktów Redgate ( http://www.red-gate.com/ ) w celu dokonania porównań. Nie są tanie, ale są warte każdego grosza.


1
w odniesieniu do danych - możesz użyć OffScale DataGrove, aby zapisać wersje całej bazy danych (w tym dane). Możesz później użyć go do odrodzenia dwóch wirtualnych kopii twojego DB, które można porównać z produktem red-gate. Oszczędza również potrzeby generowania danych testowych - możesz po prostu zapisać wersje bazy danych, aby pasowały do ​​różnych przypadków testowych (ponownie, pełne, wirtualne kopie całej bazy danych)
Taichman

1
Jak obliczyć kolejność uruchamiania skryptów bazy danych, jeśli użyto opcji „jeden plik na obiekt”?
Jamie Kitson

@Taichman: DataGrove nie obsługuje serwera SQL i jako taki nie ma związku z pytaniem.
Neolisk

38

Najpierw musisz wybrać odpowiedni dla siebie system kontroli wersji:

  • Scentralizowany system kontroli wersji - standardowy system, w którym użytkownicy sprawdzają / meldują się przed / po pracy na plikach, a pliki są przechowywane na jednym centralnym serwerze

  • Rozproszony system kontroli wersji - system, w którym klonowane jest repozytorium, a każdy klon jest w rzeczywistości pełną kopią zapasową repozytorium, więc jeśli dowolny serwer ulegnie awarii, wówczas można użyć dowolnego sklonowanego repozytorium do przywrócenia go Po wybraniu odpowiedniego systemu do potrzeb , musisz skonfigurować repozytorium, które jest rdzeniem każdego systemu kontroli wersji. Wszystko to wyjaśniono w następującym artykule: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding -source-control-basics /

Po skonfigurowaniu repozytorium, aw przypadku centralnego systemu kontroli wersji folderu roboczego, możesz przeczytać ten artykuł . Pokazuje, jak skonfigurować kontrolę źródła w środowisku programistycznym, używając:

  • SQL Server Management Studio za pośrednictwem dostawcy MSSCCI,

  • Narzędzia danych programu Visual Studio i SQL Server

  • Zewnętrzne narzędzie kontroli źródła ApexSQL

24

Tutaj w Red Gate oferujemy narzędzie SQL Source Control , które wykorzystuje technologię SQL Compare do łączenia bazy danych z repozytorium TFS lub SVN. To narzędzie integruje się z SSMS i pozwala pracować tak, jak normalnie, z wyjątkiem tego, że umożliwia teraz zatwierdzanie obiektów.

W przypadku podejścia opartego na migracjach (bardziej odpowiedniego do zautomatyzowanych wdrożeń) oferujemy SQL Change Automation (wcześniej o nazwie ReadyRoll), który tworzy i zarządza zestawem skryptów przyrostowych jako projekt Visual Studio.

W SQL Source Control można określić statyczne tabele danych. Są one przechowywane w kontroli źródła jako instrukcje INSERT.

Jeśli mówisz o danych testowych, zalecamy wygenerowanie danych testowych za pomocą narzędzia lub za pomocą zdefiniowanego skryptu po wdrożeniu, lub po prostu przywrócenie produkcyjnej kopii zapasowej do środowiska programistycznego.


Ciekawy produkt (trochę luki na rynku), ale delty zapisane jako „UTWÓRZ ...” przestraszą mnie. Jak się rozgałęziasz / łączysz?
annakata

1
Przechowujemy definicje obiektów jako UTWÓRZ, ale jeśli „pobierasz najnowsze” lub na przykład używasz SQL Compare Pro do generowania skryptów synchronizacji, zmieniają się one na odpowiednie polecenia, takie jak ALTER. Aby rozgałęzić lub scalić, wystarczy użyć systemu kontroli źródła w taki sam sposób, jak obecnie.
David Atkinson

Ta odpowiedź jest duplikatem odpowiedzi Duńczyka opublikowanej dwa lata wcześniej.
WonderWorker

To inna odpowiedź. SQL Compare nie kontroluje baz danych, podczas gdy SQL Source Control został zaprojektowany specjalnie do tego.
David Atkinson,

21

Możesz zajrzeć na Liquibase ( http://www.liquibase.org/ ). Nawet jeśli samo narzędzie nie jest używane, całkiem dobrze radzi sobie z zarządzaniem zmianami w bazie danych lub refaktoryzacją.


Używamy Liquibase w 5 rozproszonych zespołach w jednym oddziale do ciągłej dostawy i działa świetnie. Mamy ponad 10 aplikacji bazodanowych zainstalowanych w wielu różnych środowiskach. Używamy go do zarządzania schematem, indeksowaniem, partycjonowaniem, kodem, danymi wyszukiwania, grupami i uprawnieniami grup. Używamy go do Oracle, Postgresql i MSSQL.
Peter Henell,

Jeśli rozumiem poprawnie na podstawie wstępu, to musisz znać jakiś zastrzeżony język XML, aby zadeklarować swoje obiekty zamiast SQL? Nie być fanem.
JDPeckham

19

+1 dla wszystkich, którzy polecili narzędzia RedGate, z dodatkową rekomendacją i zastrzeżeniem.

SqlCompare ma również przyzwoicie udokumentowany interfejs API: możesz na przykład napisać aplikację konsoli, która synchronizuje folder skryptów kontrolowanych przez źródło z testową bazą danych integracji integracji przy zameldowaniu, dzięki czemu gdy ktoś sprawdza zmianę schematu z folderu skryptów jest automatycznie wdrażany wraz ze zgodną zmianą kodu aplikacji. Pomaga to zlikwidować różnicę w stosunku do programistów, którzy zapominają o propagowaniu zmian w lokalnej bazie danych do współużytkowanej bazy danych (chyba około połowa z nas :)).

Zastrzeżeniem jest to, że w przypadku rozwiązania skryptowego lub w inny sposób narzędzia RedGate są wystarczająco płynne, aby łatwo zapomnieć o rzeczywistości SQL leżącej u podstaw abstrakcji. Jeśli zmienisz nazwy wszystkich kolumn w tabeli, SqlCompare nie będzie w stanie odwzorować starych kolumn na nowe kolumny i usunie wszystkie dane z tabeli. Wygeneruje ostrzeżenia, ale widziałem, jak ludzie klikają to obok. Wydaje mi się, że warto tutaj ogólnie zautomatyzować wersjonowanie i aktualizowanie wersji DB - abstrakcje są bardzo nieszczelne.


Dlatego powinien istnieć system, który śledzi zmieniane kolumny i zapamiętuje mapowania ze starych nazw kolumn na nowe nazwy kolumn.
Silvercode

Warto pamiętać, że w przypadku zmian w bazie danych, które są niejednoznaczne (i dlatego wymagają elementu „intencji programisty”), odpowiednie jest rozwiązanie oparte na migracji. Redgate ma teraz ReadyRoll, który spełnia to podejście do wersjonowania.
David Atkinson

15

Korzystamy z DBGhost do zarządzania naszą bazą danych SQL. Następnie umieszczasz skrypty, aby zbudować nową bazę danych w kontroli wersji, a ona albo zbuduje nową bazę danych, albo uaktualni istniejącą bazę danych do schematu w kontroli wersji. W ten sposób nie musisz się martwić tworzeniem skryptów zmian (chociaż nadal możesz to zrobić, jeśli na przykład chcesz zmienić typ danych kolumny i musisz przekonwertować dane).


Używam DbGhost od 10 lat i nigdy mnie nie zawiodłem. Wsparcie, które zapewniają, nie ma sobie równych
penderi

15

W wersji VS 2010 użyj projektu bazy danych.

  1. Skryptuj bazę danych
  2. Wprowadź zmiany w skryptach lub bezpośrednio na serwerze db
  3. Synchronizuj za pomocą Dane> Porównaj schematy

Stanowi idealne rozwiązanie do zarządzania wersjami DB i sprawia, że ​​synchronizacja DB jest dziecinnie prosta.


2
Tak, ale niestety musisz pamiętać o „generowaniu skryptu” za każdym razem. Jeśli bezpośrednio zaktualizujesz bazę danych, utracisz możliwość wygenerowania skryptu aktualizacji dla tej delty. Gdyby tylko projekty baz danych miały wbudowaną funkcjonalność do kontroli wersji.
Jez

13

Jest to dobre podejście do zapisywania skryptów bazy danych pod kontrolą wersji za pomocą skryptów zmian, aby można było uaktualnić dowolną bazę danych. Możesz także zapisać schematy dla różnych wersji, aby można było utworzyć pełną bazę danych bez konieczności stosowania wszystkich skryptów zmian. Obsługa skryptów powinna być zautomatyzowana, abyś nie musiał wykonywać pracy ręcznej.

Uważam, że ważne jest, aby mieć osobną bazę danych dla każdego programisty i nie używać wspólnej bazy danych. W ten sposób programiści mogą tworzyć przypadki testowe i fazy programowania niezależnie od innych programistów.

Narzędzie do automatyzacji powinno mieć środki do obsługi metadanych bazy danych, które informują, które bazy danych są w stanie rozwoju i które tabele zawierają dane, które można kontrolować, i tak dalej.


12

Możesz także spojrzeć na rozwiązanie migracji. Umożliwiają one określenie schematu bazy danych w kodzie C # i przewijanie wersji bazy danych w górę iw dół za pomocą MSBuild.

Obecnie używam DbUp i działa dobrze.


11

Nie wspomniałeś o szczegółach dotyczących docelowego środowiska lub ograniczeń, więc może nie być to w pełni odpowiednie ... ale jeśli szukasz sposobu na skuteczne śledzenie ewoluującego schematu DB i nie jest to sprzeczne z pomysłem użycia Ruby, migracje ActiveRecord są na Twojej drodze.

Migracje programowo definiują transformacje bazy danych za pomocą Ruby DSL; każdą transformację można zastosować lub (zwykle) wycofać, co pozwala na przejście do innej wersji schematu DB w dowolnym momencie. Plik definiujący te transformacje można sprawdzić w kontroli wersji, jak każdy inny fragment kodu źródłowego.

Ponieważ migracje są częścią ActiveRecord , zwykle znajdują zastosowanie w aplikacjach Railsowych z pełnym stosem; jednak możesz używać ActiveRecord niezależnie od Railsów przy minimalnym wysiłku. Zobacz tutaj, aby uzyskać bardziej szczegółowe informacje na temat korzystania z migracji AR poza Railsami.


10

Każda baza danych powinna być pod kontrolą kodu źródłowego. Brakuje narzędzia do automatycznego skryptu wszystkich obiektów bazy danych - i „danych konfiguracyjnych” - do pliku, który następnie można dodać do dowolnego systemu kontroli źródła. Jeśli używasz programu SQL Server, moje rozwiązanie jest tutaj: http://dbsourcetools.codeplex.com/ . Baw się dobrze. - Nathan.


9

To proste.

  1. Gdy projekt podstawowy jest gotowy, musisz utworzyć pełny skrypt bazy danych. Ten skrypt jest zatwierdzony do SVN. To jest pierwsza wersja.

  2. Następnie wszyscy programiści tworzą skrypty zmian (ALTER ..., nowe tabele, sproki itp.).

  3. Gdy potrzebujesz bieżącej wersji, wykonaj wszystkie nowe skrypty zmian.

  4. Gdy aplikacja zostanie wydana do produkcji, wrócisz do 1 (ale wtedy będzie to oczywiście kolejna wersja).

Nant pomoże ci wykonać te skrypty zmian. :)

I pamiętaj. Wszystko działa dobrze, gdy istnieje dyscyplina. Za każdym razem, gdy zatwierdzana jest zmiana bazy danych, zatwierdzane są również odpowiednie funkcje w kodzie.


2
Po kilku latach mówię: użyj FluentMigrator (lub podobnego narzędzia dla swojej platformy).
dariol

8

Jeśli masz małą bazę danych i chcesz zaktualizować całą wersję, ten skrypt wsadowy może pomóc. Odłącza, kompresuje i sprawdza plik MDF bazy danych MSSQL w Subversion.

Jeśli chcesz przede wszystkim zaktualizować swój schemat i po prostu mieć niewielką ilość danych referencyjnych, możesz użyć Migracji SubSonic, aby sobie z tym poradzić. Zaletą jest to, że możesz łatwo migrować w górę lub w dół do dowolnej konkretnej wersji.


8

Aby zrzut do systemu kontroli kodu źródłowego był trochę szybszy, możesz zobaczyć, które obiekty zmieniły się od czasu ostatniego użycia, używając informacji o wersji w sysobjects.

Konfiguracja: Utwórz tabelę w każdej bazie danych, którą chcesz stopniowo sprawdzać, aby przechowywać informacje o wersji od ostatniego sprawdzenia (puste przy pierwszym uruchomieniu). Wyczyść tę tabelę, jeśli chcesz ponownie przeskanować całą strukturę danych.

IF ISNULL(OBJECT_ID('last_run_sysversions'), 0) <> 0 DROP TABLE last_run_sysversions
CREATE TABLE last_run_sysversions (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

Normalny tryb działania: Możesz pobrać wyniki z tej sql i wygenerować skrypty sql tylko dla tych, których jesteś zainteresowany, i umieścić je w wybranej przez Ciebie kontroli źródła.

IF ISNULL(OBJECT_ID('tempdb.dbo.#tmp'), 0) <> 0 DROP TABLE #tmp
CREATE TABLE #tmp (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

SET NOCOUNT ON

-- Insert the values from the end of the last run into #tmp
INSERT #tmp (name, id, base_schema_ver, schema_ver, type) 
SELECT name, id, base_schema_ver, schema_ver, type FROM last_run_sysversions

DELETE last_run_sysversions
INSERT last_run_sysversions (name, id, base_schema_ver, schema_ver, type)
SELECT name, id, base_schema_ver, schema_ver, type FROM sysobjects

-- This next bit lists all differences to scripts.
SET NOCOUNT OFF

--Renamed.
SELECT 'renamed' AS ChangeType, t.name, o.name AS extra_info, 1 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id
WHERE o.name <> t.name /*COLLATE*/
AND o.type IN ('TR', 'P' ,'U' ,'V')
UNION 

--Changed (using alter)
SELECT 'changed' AS ChangeType, o.name /*COLLATE*/, 
       'altered' AS extra_info, 2 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id 
WHERE (
   o.base_schema_ver <> t.base_schema_ver
OR o.schema_ver      <> t.schema_ver
)
AND  o.type IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT oi.name 
         FROM sysobjects oi INNER JOIN #tmp ti ON oi.id = ti.id
         WHERE oi.name <> ti.name /*COLLATE*/
         AND oi.type IN ('TR', 'P' ,'U' ,'V')) 
UNION

--Changed (actually dropped and recreated [but not renamed])
SELECT 'changed' AS ChangeType, t.name, 'dropped' AS extra_info, 2 AS Priority
FROM #tmp t
WHERE    t.name IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
AND  t.name IN ( SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Deleted
SELECT 'deleted' AS ChangeType, t.name, '' AS extra_info, 0 AS Priority
FROM #tmp t
WHERE NOT EXISTS (SELECT * FROM sysobjects o
                  WHERE o.id = t.id)
AND t.name NOT IN (  SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Added
SELECT 'added' AS ChangeType, o.name /*COLLATE*/, '' AS extra_info, 4 AS Priority
FROM sysobjects o
WHERE NOT EXISTS (SELECT * FROM #tmp t
                  WHERE o.id = t.id)
AND      o.type  IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
ORDER BY Priority ASC

Uwaga: Jeśli używasz niestandardowego sortowania w którejkolwiek ze swoich baz danych, musisz zastąpić /* COLLATE */je sortowaniem bazy danych. to znaczyCOLLATE Latin1_General_CI_AI


8

Ponieważ nasza aplikacja musi działać na wielu systemach RDBMS, przechowujemy naszą definicję schematu w kontroli wersji za pomocą neutralnego dla bazy danych formatu Torque (XML). Kontrolujemy również wersje danych referencyjnych dla naszej bazy danych w formacie XML w następujący sposób (gdzie „Relacja” jest jedną z tabel referencyjnych):

  <Relationship RelationshipID="1" InternalName="Manager"/>
  <Relationship RelationshipID="2" InternalName="Delegate"/>
  etc.

Następnie używamy rodzimych narzędzi do generowania aktualizacji schematu i referencyjnych skryptów aktualizacji danych, które są wymagane do przejścia z wersji X bazy danych do wersji X + 1.


7

Nie przechowujemy schematu bazy danych, przechowujemy zmiany w bazie danych. Przechowujemy zmiany schematu, dzięki czemu budujemy skrypt zmian dla dowolnej wersji bazy danych i stosujemy go do baz danych naszych klientów. Napisałem aplikację narzędzia bazy danych, która jest dystrybuowana wraz z naszą główną aplikacją, która może odczytać ten skrypt i wiedzieć, które aktualizacje należy zastosować. Ma także wystarczającą liczbę inteligentnych elementów, aby w razie potrzeby odświeżyć widoki i procedury przechowywane.


7

Musieliśmy zaktualizować naszą bazę danych SQL po migracji na platformę x64, a nasza stara wersja zepsuła się podczas migracji. Napisaliśmy aplikację C #, która używała SQLDMO do mapowania wszystkich obiektów SQL na folder:

                Korzeń
                    Nazwa serwera
                       Nazwa bazy danych
                          Obiekty schematu
                             Wyzwalacze bazy danych *
                                .ddltrigger.sql
                             Funkcje
                                ..funkcja.sql
                             Bezpieczeństwo
                                Role
                                   Role aplikacji
                                      .approle.sql
                                   Role bazy danych
                                      .role.sql
                                Schematy *
                                   .schema.sql
                                Użytkownicy
                                   .user.sql
                             Przechowywanie
                                Katalogi pełnotekstowe *
                                   .fulltext.sql
                             Procedury przechowywane
                                ..proc.sql
                             Synonimy *
                                .synonym.sql
                             Stoły
                                ..tabela.sql
                                Ograniczenia
                                   ... chkconst.sql
                                   ... defconst.sql
                                Indeksy
                                   ... index.sql
                                Klucze
                                   ... fkey.sql
                                   ... pkey.sql
                                   ... ukey.sql
                                Wyzwalacze
                                   ... trigger.sql
                             Rodzaje
                                Typy danych zdefiniowane przez użytkownika
                                   ..uddt.sql
                                Kolekcje schematów XML *
                                   ..xmlschema.sql
                             Wyświetlenia
                                ..view.sql
                                Indeksy
                                   ... index.sql
                                Wyzwalacze
                                   ... trigger.sql

Aplikacja porównałaby wówczas nowo napisaną wersję z wersją zapisaną w SVN, a gdyby wystąpiły różnice, zaktualizowałaby SVN. Ustaliliśmy, że uruchomienie procesu raz na noc było wystarczające, ponieważ nie wprowadzamy tylu zmian w SQL. Umożliwia nam śledzenie zmian we wszystkich obiektach, na których nam zależy, a także pozwala nam odbudować nasz pełny schemat w przypadku poważnego problemu.


Oooh, byłoby wspaniale udostępnić publicznie.
Chris Charabaruk,

7

Jakiś czas temu napisałem tę aplikację, http://sqlschemasourcectrl.codeplex.com/, która będzie skanować bazy danych MSFT SQL tak często, jak chcesz i automatycznie zrzuca twoje obiekty (tabele, widoki, procy, funkcje, ustawienia sql) do SVN. Działa jak marzenie. Używam go z Unfuddle (co pozwala mi otrzymywać powiadomienia o meldunkach)


6

Typowym rozwiązaniem jest zrzut bazy danych w razie potrzeby i wykonanie kopii zapasowej tych plików.

W zależności od platformy programistycznej mogą być dostępne wtyczki typu open source. Tworzenie własnego kodu w tym celu jest zwykle dość trywialne.

Uwaga: warto wykonać kopię zapasową zrzutu bazy danych zamiast poddawać ją kontroli wersji. Pliki mogą szybko uzyskać kontrolę wersji i spowodować spowolnienie całego systemu kontroli źródła (w tej chwili przypominam sobie horror CVS).


6

Właśnie zaczęliśmy korzystać z Team Foundation Server. Jeśli twoja baza danych jest średniej wielkości, wówczas studio wizualne ma fajną integrację projektu z wbudowanym porównaniem, porównaniem danych, narzędziami do refaktoryzacji bazy danych, ramą testowania bazy danych, a nawet narzędziami do generowania danych.

Ale ten model nie pasuje do bardzo dużych baz danych lub stron trzecich (które szyfrują obiekty) bardzo dobrze. Tak więc zrobiliśmy, aby przechowywać tylko nasze niestandardowe obiekty. Serwer Visual Studio / Team Foundation działa w tym przypadku bardzo dobrze.

Arch. Naczelny bazy danych TFS. blog

Strona MS TFS


6

Zgadzam się z odpowiedzią ESV iz tego właśnie powodu jakiś czas temu rozpocząłem mały projekt, aby pomóc w utrzymywaniu aktualizacji bazy danych w bardzo prostym pliku, który mógłby być następnie utrzymywany długim kodem źródłowym. Umożliwia łatwe aktualizacje dla programistów, a także UAT i produkcji. Narzędzie działa na serwerze Sql i MySql.

Niektóre funkcje projektu:

  • Umożliwia zmiany schematu
  • Umożliwia wartość populacji drzew
  • Umożliwia oddzielne wstawianie danych testowych dla np. UAT
  • Umożliwia opcję wycofania (nie zautomatyzowane)
  • Utrzymuje obsługę serwera SQL i MySQL
  • Ma możliwość zaimportowania istniejącej bazy danych do kontroli wersji za pomocą jednego prostego polecenia (tylko serwer SQL ... wciąż działa na mysql)

Kod jest hostowany w kodzie Google. Sprawdź kod Google, aby uzyskać więcej informacji

http://code.google.com/p/databaseversioncontrol/


5

Jakiś czas temu znalazłem moduł podstawowy VB, który korzystał z obiektów DMO i VSS, aby pobrać całą skrypt DB do VSS. Zamieniłem go w skrypt VB i opublikowałem tutaj . Możesz łatwo usunąć wywołania VSS i użyć DMO do wygenerowania wszystkich skryptów, a następnie wywołać SVN z tego samego pliku wsadowego, który wywołuje VBScript, aby je sprawdzić?

Dave J.


5

Korzystam również z wersji w bazie danych przechowywanej za pośrednictwem rozszerzonej rodziny procedur procedur bazy danych. Moja aplikacja ma skrypty dla każdego kroku wersji (tj. Przejście z wersji 1.1 do wersji 1.2). Po wdrożeniu sprawdza bieżącą wersję, a następnie uruchamia skrypty jeden po drugim, aż osiągnie ostatnią wersję aplikacji. Nie ma skryptu, który ma prostą „ostateczną” wersję, nawet wdrożenie na czystej bazie danych odbywa się za pomocą szeregu kroków aktualizacji.

Teraz chciałbym dodać, że dwa dni temu widziałem prezentację na kampusie MS na temat nowej i nadchodzącej edycji VS DB. Prezentacja koncentrowała się na tym temacie i zostałam wydmuchana z wody. Zdecydowanie powinieneś to sprawdzić, nowe funkcje koncentrują się na utrzymywaniu definicji schematu w skryptach T-SQL (CREATE), silniku delta środowiska wykonawczego do porównywania schematu wdrażania ze zdefiniowanym schematem oraz wykonywaniu zmian ALTER i integracji z integracją kodu źródłowego, aż do oraz w tym ciągłą integrację MSBUILD w celu automatycznego opuszczania kompilacji. Upuszczenie będzie zawierało nowy typ pliku, pliki .dbschema, które można zabrać do witryny wdrażania, a narzędzie wiersza polecenia może wykonać rzeczywiste „delty” i uruchomić wdrożenie. Mam wpis na blogu na ten temat z linkami do plików do pobrania VSDE, powinieneś je sprawdzić:http://rusanu.com/2009/05/15/version-control-and-your-database/


5

To bardzo stare pytanie, jednak wielu próbuje to rozwiązać nawet teraz. Wszystko, co muszą zrobić, to zbadać projekty Visual Studio Database. Bez tego rozwój bazy danych wygląda bardzo słabo. Od organizacji kodu, przez wdrożenie, aż po kontrolę wersji - wszystko upraszcza.


3

Z mojego doświadczenia wynika, że ​​rozwiązanie jest dwojakie:

  1. Musisz obsłużyć zmiany w bazie danych programowania, które są wykonywane przez wielu programistów podczas programowania.

  2. Musisz obsługiwać aktualizacje baz danych w witrynach klientów.

Aby obsłużyć numer 1, potrzebujesz silnego narzędzia różnicowania / scalania bazy danych. Najlepsze narzędzie powinno być w stanie wykonać automatyczne scalanie w jak największym stopniu, jednocześnie umożliwiając ręczne rozwiązywanie nieobsługiwanych konfliktów.

Idealne narzędzie powinno obsługiwać operacje scalania przy użyciu 3-kierunkowego algorytmu scalania, który uwzględnia zmiany dokonane w bazie danych THEIRS i bazie danych MINE w stosunku do bazy danych BASE.

Napisałem komercyjne narzędzie, które zapewnia obsługę ręcznego scalania baz danych SQLite, a obecnie dodaję obsługę 3-kierunkowego algorytmu scalania SQLite. Sprawdź to na stronie http://www.sqlitecompare.com

Aby poradzić sobie z numerem 2, musisz mieć zainstalowaną platformę aktualizacji.

Podstawowym pomysłem jest opracowanie struktury automatycznej aktualizacji, która wie, jak przeprowadzić aktualizację z istniejącego schematu SQL do nowszego schematu SQL i może zbudować ścieżkę aktualizacji dla każdej istniejącej instalacji DB.

Sprawdź mój artykuł na ten temat w http://www.codeproject.com/KB/database/sqlite_upgrade.aspx, aby uzyskać ogólne wyobrażenie o tym, o czym mówię.

Powodzenia

Liron Levi


3

Sprawdź DBGhost http://www.innovartis.co.uk/ . Używam w sposób zautomatyzowany od 2 lat i działa świetnie. Pozwala to na tworzenie naszych kompilacji DB podobnie jak kompilacja Java lub C, z wyjątkiem bazy danych. Wiesz co mam na myśli.


2

Sugerowałbym użycie narzędzi porównawczych do zaimprowizowania systemu kontroli wersji dla twojej bazy danych. Dobrą alternatywą są xSQL Schema Compare i xSQL Data Compare .

Teraz, jeśli Twoim celem jest kontrolowanie wersji tylko schematu bazy danych, możesz po prostu użyć porównania schematów xSQL w celu wygenerowania migawek schematu xSQL i dodać te pliki do kontroli wersji. Następnie, aby przywrócić lub zaktualizować do konkretnej wersji, po prostu porównaj bieżącą wersję bazy danych z migawką wersji docelowej.

Niestety, jeśli chcesz mieć również dane pod kontrolą wersji, możesz użyć xSQL Data Compare, aby wygenerować skrypty zmian dla swojej bazy danych i dodać pliki .sql do kontroli wersji. Następnie możesz wykonać te skrypty, aby przywrócić / zaktualizować dowolną wersję. Należy pamiętać, że w przypadku funkcji „przywracania” należy wygenerować skrypty zmian, które po wykonaniu sprawią, że wersja 3 będzie taka sama jak w wersji 2, a w przypadku funkcji „aktualizacji” należy wygenerować skrypty zmieniające działanie.

Na koniec, korzystając z podstawowych umiejętności programowania wsadowego, możesz zautomatyzować cały proces przy użyciu wersji xSQL Schema Compare i xSQL Data Compare

Oświadczenie: Jestem związany z xSQL.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.