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.

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, nie są to 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.

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.

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.

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

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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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)

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

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

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/

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.

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/

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.

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

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.

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.