Pytanie:
Narzędzia do obsługi i wdrażania schematów i danych bazy danych dla programu SQL Server?
Kenny Evitt
2014-02-05 22:09:40 UTC
view on stackexchange narkive permalink

Chciałbym zachować schemat i „statyczne” dane bazy danych SQL Server jako kod w systemie kontroli wersji. Chciałbym również móc wdrażać określone wersje kodu bazy danych w rzeczywistych instancjach odpowiedniej bazy danych, tj. Migrować bazę danych do nowej wersji (i opcjonalnie „migrować w dół” do starej wersji).

Wyjaśnienie

Bazy danych

Zakładam, że nie muszę wyjaśniać, czym jest baza danych ani że SQL Server to określony system baz danych, tj. określone oprogramowanie do zarządzania bazami danych.

Schemat bazy danych jako kod

Wśród programistów, którzy pracują z bazami danych, pożądana jest możliwość zachowania „ schematu” bazy danych, tj. informacji o jej strukturze, w postaci „ kodu”. Ten kod powinien umożliwić komuś utworzenie bazy danych z tym samym „schematem”, jaki jest reprezentowany przez kod. Kod może mieć postać instrukcji DDL ( Data Definition Language), np. Kod SQL, zwykle w jego wersji specyficznej dla dostawcy, używany do tworzenia obiektów, takich jak tabele i indeksy w bazie danych, lub może posługiwać się ogólnym językiem programowania, np Java, Ruby, C #, itp.

Kontrola wersji i kod

Gdy schemat bazy danych jest reprezentowana w kodzie, który może być utrzymywany w kontroli wersji lub systemie kontroli źródła, oprogramowaniu do zarządzania kontrolą wersji. Z Wikipedii:

Kontrola wersji, znana również jako kontrola wersji i kontrola źródła (i aspekt zarządzania konfiguracją oprogramowania), to zarządzanie zmianami w dokumentach, programach komputerowych, dużych witrynach internetowych i inne zbiory informacji.

Utrzymywanie kodu reprezentującego schemat bazy danych w systemie kontroli wersji jest pożądane, ponieważ można zachować historię zmian w schemacie, a inne narzędzia, takie jak zestaw narzędzi, o które pytam w tym pytaniu, mają dostęp schemat, nawet różne wersje schematu, do innych zastosowań.

Wdrażanie oprogramowania

Wdrażanie” w kontekście rozwoju oprogramowania i konserwacja oprogramowania obejmuje „… wszystkie czynności, które sprawiają, że system oprogramowania jest dostępny do użytku”. W kontekście tego pytania interesują mnie rekomendacje dotyczące narzędzi programowych do udostępniania określonej wersji schematu bazy danych w postaci konkretnych konkretnych instancji baz danych w SQL Server DBMS.

Przykład

Jako przykład rozważmy schemat bazy danych z wersjami v1 , v2 i v3 oraz pewną liczbę rzeczywistych baz danych , z których wszystkie mają jedną z tych wersji schematu. W przypadku tego pytania zalecane oprogramowanie powinno umożliwiać aktualizację (lub obniżenie) określonej bazy danych z jej aktualnej wersji do dowolnej innej wersji tego samego schematu i powinno używać kodu określonej wersji schematu przechowywanej w systemie kontroli wersji.

Niektóre konkretne kryteria wymienione w komentarzach

"wybierz wpis kontroli wersji zawierający schemat, (ponownie) oceń DB, aby pasował (co to dokładnie oznacza?" / p>

Schemat bazy danych jest reprezentowany jako kod w systemie kontroli wersji. Nie interesują mnie narzędzia, które współpracują bezpośrednio z kontrolą wersji. Narzędzia, o które chodzi w tym pytaniu, powinny być w stanie korzystać z „wersji” schematu bazy danych. Przykładem „wersji” schematu może być kod, który reprezentuje schemat w konkretnej wersji („zatwierdzenie” w Git) lub określony tag / etykieta do kontroli wersji systemy obsługujące takie funkcje.

Oto podstawowa lista funkcji, które powinny zostać udostępnione w narzędziu, aby „(ponownie) ocenić [docelową] bazę danych w celu dopasowania”:

Tabele

  • Jeśli tabela istnieje w schemacie źródłowym, ale nie istnieje w docelowej bazie danych, narzędzie powinno utworzyć tabelę w docelowej bazie danych. Powinno to obejmować obiekty pomocnicze, takie jak klucze, ograniczenia, wartości domyślne, indeksy, wyzwalacze itp.
  • Jeśli tabela nie istnieje w schemacie źródłowym, ale ma w docelowej bazie danych, narzędzie powinno zapewnić środki do określenia, czy tabela w docelowej bazie danych powinna zostać usunięta, czy nie. [To ustawienie może dotyczyć wszystkich takich tabel.]

Kolumny tabeli

  • Jeśli kolumna istnieje w tabeli w schemacie źródłowym, ale nie ma jej w ta sama tabela 1 w docelowej bazie danych, powinna zostać utworzona w docelowej bazie danych. Ponieważ instrukcje DDL dla większości (?) DBMS już zapewniają sposoby określenia początkowej wartości nowych kolumn dla istniejących tabel (np. Szczególnie dla nowych kolumn, które nie pozwalają na wartości NULL ), Nie mam pojęcia, czy samo narzędzie musi zapewnić coś specjalnego, aby sobie z tym poradzić. Jednakże jeśli zalecane narzędzie używa jakiejś formy „kodu schematu”, który nie jest standardowymi instrukcjami DDL odpowiedniego DBMS 2 , to narzędzie powinno zapewnić sposób określenia początkowe wartości kolumn do dodania.
  • Jeśli kolumna tabeli nie istnieje w schemacie źródłowym, ale istnieje w docelowej bazie danych, Narzędzie powinno zapewniać środki do określenia, czy kolumna w docelowej bazie danych powinna zostać usunięta, czy nie. [To ustawienie może dotyczyć wszystkich takich kolumn tabeli.]
  • Jeśli ta sama kolumna tabeli 1 istnieje zarówno w schemacie źródłowym, jak i w docelowych bazach danych, ale są one różnego typu lub występują inne różnice (np. długość, skala numeryczna itp.), narzędzie powinno zmienić kolumnę w docelowej bazie danych, aby była zgodna ze schematem źródłowym i dołożyć wszelkich starań, aby zachować istniejące dane w tej kolumnie . Jest to całkowicie poprawne, jeśli zalecane narzędzie kończy raportowanie niepowodzenia, jeśli nie jest w stanie przekonwertować istniejących danych bez utraty (np. Jeśli długość kolumny jest zmniejszona i dane musiałyby zostać obcięte).

Obiekty pomocnicze dla tabeli (y)

Niektóre przykłady tych obiektów obejmują klucze podstawowe, ograniczenia klucza obcego, wartości domyślne i indeksy.

  • Jeśli obiekt pomocniczy do jakaś tabela istnieje w schemacie źródłowym, ale nie w docelowej bazie danych, powinna zostać utworzona w docelowej bazie danych. Jak wyżej, w przypadku tworzenia nowych kolumn tabeli, narzędzie powinno być w stanie obsłużyć scenariusze obejmujące możliwe konflikty lub błędy podczas dodawania obiektu pomocniczego. Narzędzie może po prostu pozostawić to w gestii osób obsługujących kod schematu, aby upewnić się, że wszelkie konflikty lub błędy są prawidłowo obsługiwane - narzędzie może zakończyć zgłaszanie niepowodzenia, jeśli napotka taki konflikt lub błąd.
  • Jeśli obiekt pomocniczy dla jakiejś tabeli nie istnieje w schemacie źródłowym, ale istnieje w docelowej bazie danych, narzędzie powinno zapewnić środki do określenia, czy obiekt pomocniczy powinien zostać usunięty z docelowej bazy danych. [To ustawienie może dotyczyć wszystkich takich obiektów.]
  • Jeśli ten sam obiekt 1 istnieje zarówno w schemacie źródłowym, jak iw docelowej bazie danych, narzędzie powinno się zmienić (lub upuścić i odtworzyć) obiekt w docelowej bazie danych, aby pasował do schematu źródłowego.

Inne obiekty

Przez „inny obiekt” mam na myśli obiekty takie jak widoki, procedury składowane, funkcje zdefiniowane przez użytkownika itp. Obiekty te można ogólnie (?) bezpiecznie porzucić i odtworzyć. Zalecane narzędzie powinno być w stanie upuszczać i odtwarzać te obiekty w wymaganej kolejności dla obiektów, które zależą od innych takich obiektów (np. Widok, który odwołuje się do innego widoku).

  • Jeśli inny obiekt, itd., istnieje w schemacie źródłowym, ale nie w docelowej bazie danych, należy go utworzyć w docelowej bazie danych.
  • Jeśli inny obiekt, taki jak widok, bla bla bla, nie istnieje w schemacie źródłowym, ale ma w docelowej bazie danych, narzędzie powinno zapewnić pewne środki do określenia, czy inny obiekt w docelowej bazie danych powinien zostać usunięty. [To ustawienie może dotyczyć wszystkich innych obiektów.]
  • Jeśli jeden z tych obiektów istnieje zarówno w schemacie źródłowym, jak i docelowej bazie danych, narzędzie powinno zmienić (lub upuścić i odtworzyć) obiekt w docelowa baza danych, aby pasowała do schematu źródłowego.

Dane statyczne

Wiersze w tabeli zawierające dane „statyczne” do synchronizacji powinny być identyfikowane na podstawie wartości kolumn w klucz podstawowy dla tej tabeli.

Wiersze w statycznych tabelach danych w docelowej bazie danych należy zmodyfikować, aby pasowały do ​​schematu źródłowego. Wiersze w schemacie źródłowym, których nie ma w tabeli docelowej, należy wstawić do tabeli docelowej. Byłoby dobrze, gdyby narzędzie zapewniało sposób określenia, czy wiersze, które istnieją w tabeli docelowej, a nie istnieją w schemacie źródłowym, powinny zostać usunięte.

Uwagi

1 W rzeczywistości jest to potencjalnie subtelna kwestia! Większość narzędzi prawdopodobnie zaimplementuje „identyczność” dla obiektów bazy danych jako mające tę samą nazwę . Ale są alternatywy, przynajmniej dla niektórych DBMS, np. w SQL Server, rozszerzone właściwości mogą służyć do implementacji formy trwałej tożsamości dla obiektów bazy danych, która jest niezależna od nazwy obiektu. Byłoby to przydatne, ponieważ wtedy narzędzie byłoby w stanie automatycznie obsłużyć (przynajmniej niektóre) przypadki zmiany nazw obiektów.

2 Pytałem konkretnie o SQL Server, ale w tym punkt Naprawdę chciałbym, żeby ktokolwiek udzielił odpowiedzi na to pytanie w ogóle, dla dowolnego DBMS.

Dwa odpowiedzi:
#1
+3
Steve Kallestad
2014-02-19 08:09:46 UTC
view on stackexchange narkive permalink

Przed tobą jest kilka opcji.

Liquibase (bezpłatna, licencja Apache) to jedyna znana mi bezpłatna opcja obsługująca SQL Server. Jest to własny pakiet kontroli źródła, co oznacza, że ​​będziesz musiał nauczyć się innego zestawu poleceń i wymyślić rozgałęzianie, scalanie itp. Dodatkową zaletą dla Liquibase jest to, że jeśli znasz Javę, możesz zbudować własną automatyzację za pomocą bibliotek Liquibase .

Offscale (bezpłatna, nieokreślona licencja) idzie nieco dalej, umożliwiając również pobieranie zestawów danych kontroli źródła, wykonywanie zautomatyzowanych testów danego modelu za pomocą testowego zestawu danych. Niestety nie ma wsparcia dla SQL Server.

Redgate SQL Source Control to fajna opcja komercyjna. Obsługuje SQL Server, Oracle itp. Oraz wiele wypróbowanych i prawdziwych platform kontroli źródła (svn, git, mercurial, forforce itp.). Obsługuje również wersjonowanie danych. Mają produkt towarzyszący do ciągłej integracji (zautomatyzowanego wdrażania) i wiele innych narzędzi w tej samej przestrzeni. Moim zdaniem trochę za drogie do użytku osobistego, ale bardzo niedrogie do użytku korporacyjnego. Dostępna jest bezpłatna wersja próbna.

Wydaje się, że OffScale zniknęło. Witryna nie tylko nie działa, ale [najnowsza migawka z pamięci podręcznej] (https://web.archive.org/web/20180315061844/http://off-scale.com/) wydaje się, że i tak została ostatnio zaktualizowana w 2012 r. .
#2
+2
Kenny Evitt
2014-02-05 22:17:03 UTC
view on stackexchange narkive permalink

DB Ghost

Omówienie

Produkty DB Ghost spełniają wymagania.

Produkt Change Manager może generować skrypty ( Skrypty DROP i CREATE , które można uruchomić „ręcznie”) dla wszystkich obiektów schematu, a także dla danych statycznych. Produkt Change Manager Professional można w tym celu zautomatyzować za pomocą wiersza poleceń, np. do regularnego tworzenia skryptów konkretnej programistycznej bazy danych.

Produkty Packager, Packager Plus i Packager Plus Professional mogą wdrażać zmiany w postaci określonej wersji skryptów utworzonych przez Change Manager. Packager Plus może wykonać „dynamiczną aktualizację”, w zasadzie schemat i „synchronizację” danych statycznych między docelową bazą danych a źródłową bazą danych, gdzie źródłową bazę danych można utworzyć ze skryptów. Packager Plus może również utworzyć plik wykonywalny, który może być dystrybuowany w celu wykonania dynamicznej aktualizacji w odpowiednim środowisku docelowym. Packager Plus Professional można zautomatyzować, aby wykonać wszystkie wyżej wymienione czynności za pomocą wiersza poleceń.

„Synchronizacja” a migracja

Jedna powszechna strategia utrzymywania zmian w schemacie bazy danych obejmuje jawne utrzymywanie migracji bazy danych, zarówno do aktualizacji, jak i do obniżenia klasy. Migracja to faktycznie kod służący do wykonania pojedynczej zmiany w instancji bazy danych schematu.

Możesz utrzymywać migracje za pomocą DB Ghost, ale tylko zezwala robisz to, zdecydowanie nie obsługuje tego poza tym. Myślę jednak, że to dobra rzecz.

Zamiast migrować bazy danych podczas wdrażania, DB Ghost zamiast tego „synchronizuje” docelową bazę danych (bazę danych, w której chcesz wdrażać zmiany) z modelową źródłową bazą danych który jest generowany podczas wdrażania z określonej wersji schematu bazy danych. Zamiast wykonywać określone migracje, porównuje źródłowe i docelowe bazy danych i wprowadza zmiany niezbędne do docelowej bazy danych w celu rozwiązania wszelkich wykrytych różnic.

Główną zaletą synchronizacji w porównaniu z migracją jest to, że zamiast utrzymywać wszystkie skrypty dla wszystkich migracji, można (głównie) utrzymywać skrypty dla bieżącej wersji wszystkich obiektów bazy danych w schemacie . W ten sposób kod reprezentujący schemat jest zorganizowany według obiektu bazy danych, a nie rozproszony na (potencjalnie dużą) liczbę migracji.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...