Czy istnieje system kontroli wersji dla zmian struktury bazy danych?

Często napotykam następujący problem.

Pracuję nad zmianami w projekcie, które wymagają nowych tabel lub kolumn w bazie danych. Dokonuję modyfikacji bazy danych i kontynuuję pracę. Zwykle pamiętam o zapisaniu zmian, aby można je było zreplikować w systemie na żywo. Jednak nie zawsze pamiętam, co zmieniłem i nie zawsze pamiętam, aby to zapisać.

Więc pcham się do systemu na żywo i otrzymuję duży, oczywisty błąd, że nie ma NewColumnX, ugh.

Niezależnie od tego, że może to nie być najlepsza praktyka w tej sytuacji, czy istnieje system kontroli wersji dla baz danych? Nie obchodzi mnie konkretna technologia baz danych. Chcę tylko wiedzieć, czy taki istnieje. Jeśli zdarzy się, że zadziała z MS SQL Serwerem, to świetnie.

W Ruby on Rails istnieje koncepcja migracji - szybki skrypt do zmiany bazy danych.

Generujesz plik migracji, który zawiera reguły zwiększania wersji bazy danych (takie jak dodanie kolumny) i reguły obniżania wersji (takie jak usuwanie kolumny). Każda migracja jest numerowana, a tabela zawiera informacje o aktualnej wersji bazy danych.

Aby przeprowadzić migrację w górę , uruchamiasz polecenie o nazwie „db: migrate”, które sprawdza posiadaną wersję i stosuje potrzebne skrypty. Możesz migrować w dół w podobny sposób.

Same skrypty migracji są przechowywane w systemie kontroli wersji - za każdym razem, gdy zmieniasz bazę danych, wpisujesz nowy skrypt, a każdy programista może go zastosować, aby przenieść lokalną bazę danych do najnowszej wersji.

Jestem trochę oldschoolowy, do tworzenia bazy danych używam plików źródłowych. W rzeczywistości istnieją 2 pliki - project-database.sql i project-updates.sql - pierwszy dla schematu i trwałych danych, a drugi dla modyfikacji. Oczywiście oba są pod kontrolą źródła.

Kiedy baza danych się zmienia, najpierw aktualizuję główny schemat w project-database.sql, a następnie kopiuję odpowiednie informacje do pliku project-updates.sql, na przykład instrukcje ALTER TABLE. Następnie mogę zastosować aktualizacje w bazie danych deweloperskich, testować i iterować, aż wszystko będzie dobrze. Następnie wpisz pliki, przetestuj ponownie i zastosuj do produkcji.

Zwykle mam też tabelę w db - Config - na przykład:

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

Następnie dodaję do sekcji aktualizacji:

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

Zmienia się db_versiontylko wtedy, gdy baza danych jest odtwarzana, i db_revisiondaje mi wskazanie, jak daleko baza danych jest poza linią bazową.

Mogłem przechowywać aktualizacje w osobnych plikach, ale zdecydowałem się połączyć je wszystkie razem i użyć funkcji wycinania i wklejania, aby wyodrębnić odpowiednie sekcje. Trochę więcej porządków jest w porządku, tj. Usuń ':' z $ Revision 1.1 $, aby je zamrozić.

MyBatis (dawniej iBatis) ma migrację schematu , narzędzie do użycia w linii poleceń. Jest napisany w Javie, ale może być używany z dowolnym projektem.

Aby osiągnąć dobrą praktykę zarządzania zmianami w bazie danych, musimy określić kilka kluczowych celów. W związku z tym system migracji schematu MyBatis (lub w skrócie migracje MyBatis) ma na celu:

• Pracuj z dowolną bazą danych, nową lub istniejącą
• Wykorzystaj system kontroli źródła (np. Subversion)
• Umożliwiaj współbieżnym programistom lub zespołom niezależną pracę
• Pozwalaj na bardzo widoczne i łatwe do opanowania konflikty
• Zezwalaj na migrację do przodu i do tyłu (odpowiednio ewoluuj, rozwijaj)
• Spraw, aby aktualny stan bazy danych był łatwo dostępny i zrozumiały
• Włącz migracje pomimo uprawnień dostępu lub biurokracji
• Pracuj z dowolną metodologią
• Zachęca do dobrych, konsekwentnych praktyk

Redgate ma produkt o nazwie SQL Source Control . Integruje się z TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce i Git.

Bardzo polecam SQL delta . Po prostu używam go do generowania skryptów porównawczych, gdy skończę kodować moją funkcję i sprawdzam te skrypty w moim narzędziu kontroli źródła (Mercurial :))

Mają zarówno wersję serwera SQL, jak i Oracle.

Zastanawiam się, że nikt nie wspomniał o narzędziu Liquibase o otwartym kodzie źródłowym, które jest oparte na Javie i powinno działać dla prawie każdej bazy danych obsługującej jdbc. W porównaniu do railsów używa XML zamiast ruby ​​do wykonywania zmian schematu. Chociaż nie lubię xml dla języków specyficznych dla domeny, bardzo fajną zaletą xml jest to, że liquibase wie, jak cofnąć pewne operacje, takie jak

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

Więc nie musisz zajmować się tym samodzielnie

Obsługiwane są również czyste instrukcje sql lub import danych.

Większość silników baz danych powinna obsługiwać zrzucanie bazy danych do pliku. W każdym razie wiem, że MySQL to robi. Będzie to po prostu plik tekstowy, więc możesz przesłać go do Subversion lub cokolwiek innego, czego używasz. Łatwo byłoby również uruchomić różnicę na plikach.

Jeśli używasz SQL Server, trudno byłoby pokonać Data Dude (inaczej Database Edition programu Visual Studio). Kiedy już to zrozumiesz, porównanie schematu między wersją bazy danych kontrolowaną przez źródła a wersją produkcyjną jest bardzo proste. Jednym kliknięciem możesz wygenerować swój różnicowy DDL.

W witrynie MSDN znajduje się film instruktażowy, który jest bardzo pomocny.

Wiem o DBMS_METADATA i Ropuchu, ale gdyby ktoś mógł wymyślić Data Dude dla Oracle, to życie byłoby naprawdę słodkie.

Niech początkowo utwórz instrukcje tabeli w kontrolerze wersji, a następnie dodaj instrukcje alter table, ale nigdy nie edytuj plików, po prostu więcej plików zmian, najlepiej nazwanych sekwencyjnie lub nawet jako „zbiór zmian”, aby można było znaleźć wszystkie zmiany dla konkretnego wdrożenia.

Najtrudniejszą częścią, jaką widzę, jest śledzenie zależności, np. Dla konkretnego wdrożenia tabela B może wymagać aktualizacji przed tabelą A.

W przypadku Oracle używam Toad , który może zrzucić schemat do wielu oddzielnych plików (np. Jeden plik na tabelę). Mam kilka skryptów zarządzających tą kolekcją w Perforce, ale myślę, że powinno to być łatwe do wykonania w prawie każdym systemie kontroli wersji.

Spójrz na pakiet Oracle DBMS_METADATA.

W szczególności przydatne są następujące metody:

• DBMS_METADATA.GET_DDL
• DBMS_METADATA.SET_TRANSFORM_PARAM
• DBMS_METADATA.GET_GRANTED_DDL

Po zapoznaniu się z ich działaniem (dość oczywiste) możesz napisać prosty skrypt, który zrzuci wyniki tych metod do plików tekstowych, które można umieścić pod kontrolą źródła. Powodzenia!

Nie jestem pewien, czy jest coś tak prostego w MSSQL.

Piszę moje skrypty wydania db równolegle z kodowaniem i trzymam skrypty wydania w sekcji specyficznej dla projektu w SS. Jeśli wprowadzam zmianę w kodzie wymagającą zmiany bazy danych, aktualizuję jednocześnie skrypt wydania. Przed wydaniem uruchamiam skrypt wydania na czystej bazie deweloperskiej (skopiowanej z produkcyjną strukturą) i wykonuję na niej końcowe testy.

Robiłem to z przerwami od lat - zarządzam (lub próbuję zarządzać) wersjami schematów. Najlepsze podejście zależy od posiadanych narzędzi. Jeśli możesz zdobyć narzędzie Quest Software „Menedżer schematów”, będziesz w dobrej formie. Oracle ma swoje własne, gorsze narzędzie, które jest również nazywane „Menedżerem schematów” (mylące?), Którego nie polecam.

Bez zautomatyzowanego narzędzia (zobacz inne komentarze na temat Data Dude) będziesz używać bezpośrednio skryptów i plików DDL. Wybierz podejście, udokumentuj je i ściśle przestrzegaj. Lubię mieć możliwość odtworzenia bazy danych w dowolnym momencie, więc wolę mieć pełny eksport DDL całej bazy danych (jeśli jestem DBA) lub schematu programisty (jeśli jestem w produkcie -Tryb rozwoju).

PLSQL Developer, narzędzie firmy All Arround Automations, ma wtyczkę do repozytoriów, która działa dobrze (ale nie świetnie) z Visual Source Safe.

Z sieci:

Wtyczka kontroli wersji zapewnia ścisłą integrację między PL / SQL Developer IDE >> a dowolnym systemem kontroli wersji obsługującym specyfikację interfejsu Microsoft SCC. >> Obejmuje to najpopularniejsze systemy kontroli wersji, takie jak Microsoft Visual SourceSafe, >> Merant PVCS i MKS Source Integrity.

http://www.allroundautomations.com/plsvcs.html

ER Studio umożliwia odwrócenie schematu bazy danych do narzędzia, a następnie porównanie go z aktywnymi bazami danych.

Przykład: Odwróć swój schemat rozwoju do ER Studio - porównaj go z produkcją, a wyświetli listę wszystkich różnic. Może zapisywać zmiany lub po prostu automatycznie je wprowadzać.

Gdy masz już schemat w ER Studio, możesz zapisać skrypt tworzenia lub zapisać go jako zastrzeżony plik binarny i zapisać go w kontroli wersji. Jeśli kiedykolwiek zechcesz wrócić do poprzedniej wersji schematu, po prostu sprawdź ją i prześlij na swoją platformę db.

Istnieje „platforma migracji bazy danych” PHP5 o nazwie Ruckusing. Nie korzystałem z tego, ale przykłady pokazują ideę, jeśli używasz języka do tworzenia bazy danych w razie potrzeby, wystarczy śledzić pliki źródłowe.

W programie Visual Studio można używać narzędzi Microsoft SQL Server Data Tools do generowania skryptów dla obiektów bazy danych w ramach projektu SQL Server. Następnie można dodać skrypty do kontroli źródła przy użyciu integracji kontroli źródła wbudowanej w program Visual Studio. Ponadto projekty SQL Server umożliwiają weryfikację obiektów bazy danych za pomocą kompilatora i generowanie skryptów wdrażania w celu zaktualizowania istniejącej bazy danych lub utworzenia nowej.

Użyliśmy MS Team System Database Edition z całkiem niezłym sukcesem. Integruje się z kontrolą wersji TFS i Visual Studio mniej lub bardziej płynnie i pozwala nam łatwo zarządzać przechowywanymi procesami, widokami itp. Rozwiązywanie konfliktów może być uciążliwe, ale po zakończeniu historia wersji jest kompletna. Następnie migracje do kontroli jakości i produkcji są niezwykle proste.

Można śmiało powiedzieć, że jest to produkt w wersji 1.0 i nie jest pozbawiony kilku problemów.

Schema Compare for Oracle to narzędzie zaprojektowane specjalnie do migracji zmian z naszej bazy danych Oracle do innej. Odwiedź poniższy adres URL, aby uzyskać link do pobrania, dzięki któremu będziesz mógł korzystać z oprogramowania w celu uzyskania w pełni funkcjonalnej wersji próbnej.

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

Wobec braku VCS dla zmian tabel, zapisywałem je na wiki. Przynajmniej wtedy widzę, kiedy i dlaczego został zmieniony. Jest daleki od ideału, ponieważ nie wszyscy to robią i mamy w użyciu wiele wersji produktów, ale lepsze niż nic.

Poleciłbym jedno z dwóch podejść. Najpierw zainwestuj w PowerDesigner firmy Sybase. Wersja Enterprise. Umożliwia projektowanie fizycznych modeli danych i wiele więcej. Ale zawiera repozytorium, które pozwala na sprawdzanie modeli. Każde nowe zgłoszenie może być nową wersją, może porównać dowolną wersję z dowolną inną wersją, a nawet z tym, co jest w Twojej bazie danych w tym czasie. Następnie przedstawi listę wszystkich różnic i zapyta, które powinny zostać poddane migracji… a następnie zbuduje skrypt, aby to zrobić. Nie jest tani, ale jest to okazja za dwa razy wyższą cenę, a zwrot z inwestycji wynosi około 6 miesięcy.

Innym pomysłem jest włączenie kontroli DDL (działa w Oracle). Spowoduje to utworzenie tabeli z każdą wprowadzoną zmianą. Jeśli zapytasz o zmiany od sygnatury czasowej, w której ostatnio przeniosłeś zmiany w bazie danych do teraz, uzyskasz uporządkowaną listę wszystkiego, co zrobiłeś. Kilka klauzul where eliminujących zmiany o sumie zerowej, takie jak create table foo; po którym następuje drop table foo; i możesz ŁATWO zbudować skrypt modowy. Po co zachowywać zmiany na wiki, to podwójna praca. Pozwól bazie danych śledzić je za Ciebie.

Dwie rekomendacje książek: „Refactoring Databases” autorstwa Ambler i Sadalage oraz „Agile Database Techniques” autorstwa Ambler.

Ktoś wspomniał o migracjach Railsów. Myślę, że działają świetnie, nawet poza aplikacjami Railsowymi. Użyłem ich w aplikacji ASP z SQL Server, którą byliśmy w trakcie przenoszenia na Railsy. Sprawdzasz same skrypty migracji w VCS. Oto post Pragmatic Dave Thomas na ten temat.