Mechanizmy śledzenia zmian schematu DB [zamknięte]

Używamy czegoś podobnego do bcwoord, aby zsynchronizować nasze schematy bazy danych w 5 różnych instalacjach( produkcja, staging i kilka instalacji deweloperskich), a także wykonać kopię zapasową w kontroli wersji i działa całkiem dobrze. Trochę rozbuduję:

Aby zsynchronizować strukturę bazy danych, mamy jeden skrypt, update.php, oraz liczba plików ponumerowanych 1.sql, 2sql, 3sql, itp. Skrypt wykorzystuje jedną dodatkową tabelę do przechowywania bieżącego numeru wersji bazy danych. Na N. pliki sql są tworzone ręcznie, aby przejść z wersji (N-1) do wersji N bazy danych.

Mogą być używane do dodawania tabel, dodawania kolumn, migracji danych ze starego do nowego formatu kolumny, a następnie opuszczania kolumny, wstawiania wierszy danych "master", takich jak typy użytkowników, itp. Zasadniczo może zrobić wszystko, a dzięki odpowiednim skryptom migracji danych nigdy nie utracisz danych.

Skrypt aktualizacji działa tak:

• Połącz się z bazą danych.
• zrób kopię zapasową bieżąca baza danych (ponieważ coś będzie pójdzie nie tak) [mysqldump].
• Utwórz tabelę księgową (o nazwie _meta), jeśli nie istnieje.
• odczyt bieżącej wersji z tabeli _meta. Załóżmy 0, jeśli nie znaleziono.
• dla wszystkich .pliki sql numerowane wyżej niż wersja, wykonuj je w kolejności
• Jeśli w jednym z plików wystąpił błąd: wróć do kopii zapasowej
• w przeciwnym razie Zaktualizuj wersję w tabeli księgowej do najwyższej .wykonany plik sql.

Wszystko przechodzi w kontrolę źródła, a każda instalacja ma skrypt do aktualizacji do najnowszej wersji z jednym wykonaniem skryptu (wywołanie update.php z odpowiednim hasłem do bazy danych itp.). SVN aktualizuje środowiska stagingowe i produkcyjne za pomocą skryptu, który automatycznie wywołuje skrypt aktualizacji bazy danych, więc aktualizacja kodu pochodzi z niezbędnymi aktualizacjami bazy danych.

Możemy również użyć tego samego skryptu do odtworzenia całej bazy danych od zera; po prostu upuszczamy i odtworzyć bazę danych, a następnie uruchomić skrypt, który całkowicie wypełni bazę danych. Możemy również użyć skryptu do wypełnienia pustej bazy danych w celu automatycznego testowania.

uważaj jednak podczas wklejania zapytań z phpMyAdmin! te generowane zapytania zwykle zawierają nazwę bazy danych, której na pewno nie chcesz, ponieważ zepsuje twoje Skrypty! Coś w rodzaju CREATE TABLE mydb.newtable(...) nie powiedzie się, jeśli baza danych w systemie nie zostanie wywołana mydb. Stworzyliśmy hak SVN z komentarzem wstępnym, który będzie wykluczał .pliki sql zawierające łańcuch mydb, który jest pewnym znakiem, że ktoś skopiował / wkleił z phpMyAdmin bez odpowiedniego sprawdzam.

Mój zespół Skrypty wszystkie zmiany bazy danych, i zobowiązuje te skrypty do SVN, wraz z każdym wydaniem aplikacji. Pozwala to na stopniowe zmiany bazy danych, bez utraty danych.

Aby przejść z jednego wydania do drugiego, wystarczy uruchomić zestaw skryptów zmiany, a baza danych jest aktualna i nadal masz wszystkie swoje dane. Może nie jest to najłatwiejsza metoda, ale zdecydowanie jest skuteczna.

Problem tutaj naprawdę ułatwia programistom pisanie własnych lokalnych zmian do kontroli źródeł, aby podzielić się nimi z zespołem. Od wielu lat borykam się z tym problemem i zainspirowała mnie funkcjonalność Visual Studio dla specjalistów od baz danych. Jeśli chcesz mieć narzędzie open-source z tymi samymi funkcjami, spróbuj tego: http://dbsourcetools.codeplex.com/ Baw się dobrze, - Nathan.

Jeśli nadal szukasz rozwiązań: proponujemy narzędzie o nazwie neXtep designer. Jest to środowisko programistyczne bazy danych, za pomocą którego można umieścić całą bazę danych pod kontrolą wersji. Pracujesz na repozytorium kontrolowanym przez wersję, w którym można śledzić każdą zmianę.

Gdy musisz wydać aktualizację, możesz zatwierdzić swoje komponenty, a produkt automatycznie wygeneruje skrypt aktualizacji SQL z poprzedniej wersji. Oczywiście możesz wygenerować ten SQL z dowolne 2 wersje.

Wtedy masz wiele opcji: możesz wziąć te skrypty i umieścić je w swoim SVN z kodem aplikacji, tak aby były wdrożone przez istniejący mechanizm. Inną opcją jest użycie mechanizmu dostarczania neXtep : skrypty są eksportowane w coś, co nazywa się "pakietem dostarczania" (skrypty SQL + deskryptor XML), a instalator może zrozumieć ten pakiet i wdrożyć go do serwera docelowego, zapewniając jednocześnie spójność strcutural, sprawdzanie zależności, rejestrowanie zainstalowanych wersja itp.

Produkt jest GPL i jest oparty na Eclipse, więc działa na Linuksie, Mac i windows. Obsługuje również Oracle, Mysql i Postgresql w tej chwili (wsparcie DB2 jest w drodze). Zajrzyj na wiki, gdzie znajdziesz bardziej szczegółowe informacje : http://www.nextep-softwares.com/wiki

Zrzuć swój schemat do pliku i dodaj go do kontroli źródła. Następnie prosty diff pokaże ci, co się zmieniło.

Scott Ambler tworzy świetną serię artykułów (i jest współautorem Książki) na temat refaktoryzacji baz danych, z myślą, że powinieneś zasadniczo stosować zasady i praktyki TDD do utrzymywania swojego schematu. Skonfigurujesz serię testów jednostkowych struktury i danych nasiennych dla bazy danych. Następnie, zanim cokolwiek zmienisz, modyfikujesz / piszesz testy, aby odzwierciedlić tę zmianę.

Robimy to już od jakiegoś czasu i wydaje się, że działa. Napisaliśmy kod do wygenerowania podstawowej nazwy kolumny i kontrola typu danych w pakiecie testów jednostkowych. Możemy ponownie uruchomić te testy w dowolnym momencie, aby sprawdzić, czy baza danych w kasie SVN pasuje do aktywnego db, w którym aplikacja jest faktycznie uruchomiona.

Jak się okazuje, deweloperzy również czasami poprawiają swoją bazę sandboxów i zaniedbują aktualizację pliku schematu w SVN. Kod zależy wtedy od zmiany db, która nie została sprawdzona. Tego rodzaju błąd może być szalenie trudny do wykrycia, ale zestaw testów natychmiast go wykryje. Jest to szczególnie dobrze, jeśli masz go wbudowany w większy plan ciągłej integracji.

To trochę mało zaawansowana technologia i może być lepsze rozwiązanie, ale możesz po prostu zapisać swój schemat w skrypcie SQL, który można uruchomić, aby utworzyć bazę danych. Myślę, że można wykonać polecenie, aby wygenerować ten skrypt, ale nie znam polecenia niestety.

Następnie zatwierdź skrypt do kontroli źródła wraz z kodem, który na nim działa. Gdy trzeba zmienić schemat wraz z kodem, skrypt można sprawdzić wraz z kodem, który wymaga zmieniony schemat. Następnie diffs na skrypcie wskaże diffs na zmiany schematu.

Za pomocą tego skryptu można zintegrować go z Dbunitem lub jakimś skryptem budowania, więc wydaje się, że może pasować do już zautomatyzowanych procesów.

Jeśli używasz C#, spójrz na Subsonic, bardzo przydatne narzędzie ORM, ale również generuje skrypt sql do odtworzenia schematu i danych\or. Skrypty te mogą być następnie wprowadzone do kontroli źródła.

Http://subsonicproject.com/

K. Scott Allen ma przyzwoity artykuł lub dwa na temat wersjonowania schematu, który używa koncepcji przyrostowych skryptów aktualizacji/migracji, o których mowa w innych odpowiedziach tutaj; zobacz http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx .

Użyłem poniższej struktury projektu bazy danych w Visual Studio dla kilku projektów i działa całkiem dobrze:

Baza danych

Zmień Skrypty

0.PreDeploy.sql

1.Schemach.sql

2.DataChanges.sql

3.Uprawnienia.sql

Tworzenie Skryptów

Sprocks

Funkcje

Views

Nasza Budowa następnie system aktualizuje bazę danych z jednej wersji do następnej, wykonując skrypty w następującej kolejności:

1.PreDeploy.sql

2.Schemach.sql

Zawartość folderu Create Scripts

2.DataChanges.sql

3.Uprawnienia.sql

Każdy programista sprawdza zmiany pod kątem konkretnego błędu / funkcji, dołączając swój kod na końcu każdego pliku. Gdy główna wersja jest kompletna i rozgałęziona w kontroli źródła, zawartość ... pliki sql w folderze Zmień skrypty są usuwane.

Używamy bardzo prostego, ale skutecznego rozwiązania.

Dla nowych instalacji, mamy metadane.plik sql w repozytorium, który zawiera cały schemat DB, następnie w procesie budowania używamy tego pliku do generowania bazy danych.

W przypadku aktualizacji dodajemy aktualizacje w oprogramowaniu zakodowanym na twardo. Trzymamy to na twardo, ponieważ nie lubimy rozwiązywać problemów, zanim to naprawdę jest problemem, a tego rodzaju rzeczy nie okazały się problemem do tej pory.

Więc w naszym oprogramowaniu mamy coś takiego:

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

Ten kod sprawdzi, czy baza danych jest w wersji 1 (która jest przechowywana w tabeli tworzonej automatycznie), czy jest nieaktualna, wtedy zostanie wykonane polecenie.

Aby zaktualizować metadane.sql w repozytorium uruchamiamy lokalnie, a następnie wyodrębniamy pełne metadane bazy danych.

Jedyną rzeczą, która zdarza się tak często, jest zapomnieć o commiting metadanych.sql, ale nie jest to poważny problem, ponieważ jest łatwy do przetestowania na kompilacji proces, a także jedyną rzeczą, która może się zdarzyć, jest wykonanie nowej instalacji z przestarzałą bazą danych i zaktualizowanie jej przy pierwszym użyciu.

Również nie obsługujemy downgrades, ale to z założenia, jeśli coś zepsuje się na aktualizacji, przywróciliśmy poprzednią wersję i naprawić aktualizację przed ponowną próbą.

Tworzę foldery nazwane po wersjach build i umieszczam tam skrypty upgrade i downgrade. Na przykład możesz mieć następujące foldery: 1.0.0, 1.0.1 i 1.0.2. Każdy z nich zawiera skrypt, który pozwala na uaktualnienie lub obniżenie wersji bazy danych między wersjami.

Jeśli klient lub klient zadzwoni do Ciebie z problemem z wersją 1.0.1 i używasz wersji 1.0.2, przywrócenie bazy danych do jego wersji nie będzie problemem.

W bazie danych utwórz tabelę nazywa się "schemat", gdzie można umieścić w bieżącej wersji bazy danych. Następnie pisanie programu, który może uaktualnić lub obniżyć wersję bazy danych dla Ciebie jest łatwe.

Tak jak powiedział Joey, jeśli jesteś w świecie Rails, użyj migracji. :)

W moim obecnym projekcie PHP wykorzystujemy ideę migracji rails i mamy katalog migracji, w którym przechowujemy tytuł pliku "migration_XX. sql", gdzie XX To numer migracji. Obecnie pliki te są tworzone ręcznie, jak aktualizacje są wykonane, ale ich tworzenie można łatwo zmodyfikować.

Następnie mamy skrypt o nazwie "Migration_watcher", który, jak jesteśmy w pre-alpha, aktualnie uruchamia się przy każdym ładowaniu strony i sprawdza, czy istnieje nowy plik migration_XX.sql, gdzie XX jest większy niż aktualna wersja migracji. Jeśli tak, to uruchamia wszystkie pliki migration_XX. sql do największej liczby w bazie danych i voila! zmiany schematu są zautomatyzowane.

Jeśli potrzebujesz możliwości przywrócenia systemu, wymagałoby to wielu poprawek, ale jest to proste i działa bardzo dobrze dla naszego dość małego zespołu do tej pory.

Zalecałbym użycie Ant (cross platform) dla strony" skryptowej " (ponieważ może praktycznie rozmawiać z dowolnym db tam przez jdbc) i Subversion dla repozytorium źródłowego. Ant pozwoli Ci "wykonać kopię zapasową" Twojego db do plików lokalnych, przed dokonaniem zmian. 1. kopia zapasowa istniejącego schematu db do pliku przez Ant 2. Kontrola wersji do repozytorium Subversion przez Ant 3. wysyłanie nowych poleceń sql do db przez Ant

Toad dla MySQL posiada funkcję o nazwie Schema compare, która pozwala na synchronizację 2 baz danych. Jest to najlepsze narzędzie, z którego dotychczas korzystałem.

IMHO migracje mają ogromny problem:

Aktualizacja z jednej wersji do drugiej działa dobrze, ale wykonanie nowej instalacji danej wersji może zająć wieczność, jeśli masz setki tabel i długą historię zmian(tak jak my).

Uruchomienie całej historii deltas od linii bazowej do bieżącej wersji (dla setek baz klientów) może zająć bardzo dużo czasu.

Podoba mi się sposób, w jaki Yii obsługuje migracje baz danych. Migracja jest w zasadzie skryptem PHP realizującym CDbMigration. CDbMigration definiuje metodę up zawierającą logikę migracji. Możliwe jest również wdrożenie metody down w celu wsparcia odwrócenia migracji. Alternatywnie można użyć safeUp lub safeDown, aby upewnić się, że migracja odbywa się w kontekście transakcji.

Narzędzie wiersza poleceń Yii yiic zawiera wsparcie dla tworzenia i wykonywania migracji. Migracje mogą być stosowane lub odwrócone, pojedynczo lub wsadowo. Tworzenie migracji skutkuje kodem dla klasy PHP implementującej CDbMigration, o unikalnej nazwie opartej na znaczniku czasu i nazwie migracji określonej przez użytkownika. Wszystkie migracje, które zostały wcześniej zastosowane do bazy danych, są przechowywane w tabeli migracji.

Więcej informacji można znaleźć w artykule migracja bazy danych z podręcznika.

Spróbuj db-deploy - głównie narzędzie Java, ale działa również z php.

• http://dbdeploy.com/
• http://davedevelopment.co.uk/2008/04/14/how-to-simple-database-migrations-with-phing-and-dbdeploy.html

Istnieje wiersz poleceń mysql-diff narzędzie, które porównuje schematy bazy danych, gdzie schematem może być aktywna baza danych lub skrypt SQL na dysku. Jest to dobre dla większości zadań migracji schematu.