Mechanizmy śledzenia zmian schematu DB

głosy
128

Jakie są najlepsze sposoby śledzenia i / lub zautomatyzowanie zmian schematu DB? Nasz zespół używa Subversion dla kontroli wersji i byliśmy w stanie zautomatyzować niektóre z naszych zadań w ten sposób (popychanie buduje się na serwerze pomostowym, wdrażania przetestowany kod na serwerze produkcyjnym), ale my wciąż ręcznie robi aktualizacji bazy danych. Chciałbym znaleźć lub stworzyć rozwiązanie, które pozwala nam skutecznie działać na serwerach z różnych środowiskach przy jednoczesnym użyciu Subversion jako backend przez który kod i DB aktualizacje są popychani do różnych serwerów.

Wiele popularnych pakietów oprogramowania zawierają skrypty automatycznej aktualizacji, które wykrywają wersję DB i zastosowania niezbędnych zmian. Jest to najlepszy sposób, aby to zrobić nawet na większą skalę (w wielu projektach i czasami wielu środowisk i języków)? Jeśli tak, to czy jest jakiś istniejący kod tam, że upraszcza proces czy jest to najlepiej po prostu toczyć własne rozwiązania? Ma ktoś coś podobnego wdrożone przed i zintegrować go do Subversion post-commit haki, czy jest to zły pomysł?

Choć rozwiązanie, które obsługuje wiele platform byłoby lepiej, na pewno trzeba wspierać Linux / Apache / MySQL / PHP stos jak większość naszej pracy jest na tej platformie.

Utwórz 04/08/2008 o 22:31
źródło użytkownik
W innych językach...                            


20 odpowiedzi

głosy
54

W świecie Rails, istnieje pojęcie migracje, skrypty, w których zmiany w bazie danych są dokonywane w Ruby zamiast smaku specyficzne dla bazy danych SQL. Twój kod Ruby migracja kończy się przekształcić w konkretnych DDL do aktualnej bazy danych; to sprawia, że ​​przełączanie platformy bazodanowe bardzo łatwe.

Dla każdej zmiany wprowadzone do bazy danych, piszesz nową migracją. Migracje mają zwykle dwie metody: AN „w górę” metoda, w której stosuje się zmienia i „w dół” metoda, w której zmiany są cofnięte. Pojedyncza komenda prowadzi bazę danych na bieżąco, a także może być używany w celu doprowadzenia bazy danych do konkretnej wersji schematu. W Rails, migracje są utrzymywane w swoim katalogu w katalogu projektu i zostaną sprawdzone pod kontrolą wersji, tak jak każdy inny kod projektu.

Ten Oracle przypomnienie Rails migracji obejmuje migracje całkiem dobrze.

Programiści korzystający z innych języków spojrzał na migracje i wdrożyły własne wersje danego języka. Znam Ruckusing , system migracje PHP, który jest wzorowany na migracje Rails; to może być to, czego szukasz.

Odpowiedział 04/08/2008 o 23:45
źródło użytkownik

głosy
48

Używamy coś podobnego do bcwoord aby nasze schematy baz danych zsynchronizowane na 5 różnych urządzeń (produkcja, inscenizacji i kilku instalacji Rozwoju) i wsparte w kontroli wersji, i to działa całkiem dobrze. Będę trochę rozwinąć:


Aby zsynchronizować struktury bazy danych, mamy jeden skrypt, update.php oraz liczbę plików ponumerowanych 1.sql, 2.sql, 3.sql itp Skrypt wykorzystuje jeden dodatkowy stół do przechowywania aktualny numer wersji Baza danych. Pliki N.sql są wykonane ręcznie, aby przejść od wersji (N-1) do wersji N bazy danych.

Mogą być używane do dodawania tabel, dodać kolumny, migracji danych ze starego do nowego formatu kolumny następnie upuścić kolumnę, wstawić „master” wierszy danych, takie jak typy użytkowników, itp Zasadniczo, to może nic zrobić, a wraz z odpowiednimi danymi skrypty migracji nigdy nie stracić danych.

Skrypt aktualizacja działa tak:

  • Połączenia z bazą danych.
  • Zrób kopię zapasową bieżącej bazy danych (ponieważ materiał będzie pomylić) [mysqldump].
  • Tworzenie tabeli księgowych (zwany _meta), jeśli nie istnieje.
  • Czytaj aktualną wersję ze _meta tabeli. Zakładamy, 0 jeśli nie znaleziono.
  • Dla wszystkich plików .sql ponumerowane wyższy niż wersja, wykonać je w kolejności
  • Jeżeli jeden z plików produkowane błąd: przywrócić do kopii zapasowej
  • W przeciwnym razie, należy zaktualizować wersję w tabeli księgowości na najwyższym pliku .sql wykonywany.

Wszystko idzie do kontroli źródła, a każda instalacja ma skrypt do aktualizacji do najnowszej wersji z pojedynczym wykonywania skryptu (wywołującego update.php z właściwym hasłem bazy danych itp.) Mamy svn update inscenizację i środowisk produkcyjnych poprzez skrypt, który automatycznie wywołuje skrypt aktualizacji bazy danych, a więc zmiana kodu pochodzi z niezbędnych aktualizacji baz danych.

Możemy również użyć tego samego skryptu, aby odtworzyć całą bazę danych od podstaw; po prostu usunąć i odtworzyć bazę danych, a następnie uruchomić skrypt, który będzie całkowicie repopulate bazy danych. Możemy również użyć skryptu do wypełnienia pustej bazy danych do automatycznego testowania.


Minęło zaledwie kilka godzin, aby skonfigurować ten system, to jest koncepcyjnie proste i każdy dostaje schemat numeracji wersji i to było bezcenne posiadające zdolność do poruszania się do przodu i rozwija projekt bazy danych, bez konieczności komunikowania się lub ręcznie wykonać modyfikacje na wszystkich baz danych.

Strzeż się podczas wklejania zapytań od phpMyAdmin chociaż! Generowanych zapytań zazwyczaj zawierają nazwę bazy danych, która na pewno nie chcesz, ponieważ będzie przerwa skryptów! Coś jak CREATE TABLE mydb. newtable(...) nie powiedzie się, jeśli baza danych w systemie nie nazywa mojabd. Stworzyliśmy SVN hak pre-komentarz, który uniemożliwi .sql pliki zawierające mydbciąg znaków, który jest pewny znak, że ktoś kopiowania / wklejania z phpMyAdmin bez właściwej kontroli.

Odpowiedział 22/08/2008 o 15:44
źródło użytkownik

głosy
11

Moje skrypty zespół spośród wszystkich zmian w bazie danych, a także zobowiązuje te skrypty do SVN, wraz z każdym wydaniem aplikacji. Pozwala to na stopniowych zmian w bazie danych, bez utraty żadnych danych.

Aby przejść z jednej wersji do drugiej, wystarczy uruchomić zestaw skryptów zmienić, a baza danych jest up-to-date, a wciąż masz wszystkie swoje dane. To nie może być najprostsza metoda, ale na pewno jest skuteczny.

Odpowiedział 05/08/2008 o 20:56
źródło użytkownik

głosy
9

Jeśli wciąż szukasz rozwiązań: proponujemy narzędzie o nazwie neXtep projektant. Jest to środowisko programistyczne bazy danych, z którą można umieścić całą swoją bazę danych pod kontrolą wersji. Pracujesz na wersji kontrolowane repozytorium, gdzie każda zmiana może być śledzone.

Kiedy trzeba wydać aktualizacji można popełnić komponentów, a produkt zostanie automatycznie generuje skrypt SQL aktualizacji z poprzedniej wersji. Oczywiście, można wygenerować ten SQL z dowolnego 2 wersjach.

Wtedy masz wiele opcji: można wziąć te skrypty i umieścić je w SVN z kodem aplikacji, dzięki czemu zostanie on wdrożony przez istniejącego mechanizmu. Inną opcją jest użycie mechanizmu dostarczania neXtep: skrypty są eksportowane w czymś o nazwie „pakiet dostawy” (skrypty SQL + deskryptora XML), a instalator może zrozumieć ten pakiet i wdrożyć go do serwera docelowego przy jednoczesnym zapewnieniu strcutural konsystencję, zależność sprawdzić, rejestracji zainstalowaną wersję itp

Produkt jest GPL i jest oparte na Eclipse tak, że działa na Linux, Mac i Windows. Należy również wspierać Oracle, MySQL i PostgreSQL w tej chwili (wsparcie DB2 jest w drodze). Zajrzyj na wiki, gdzie można znaleźć bardziej szczegółowe informacje: http://www.nextep-softwares.com/wiki

Odpowiedział 25/10/2010 o 06:46
źródło użytkownik

głosy
9

Problem tutaj jest naprawdę co ułatwia programistom skrypt własne lokalne zmienia się w kontroli źródła, aby dzielić się z zespołem. Mam wobec tego problemu przez wiele lat i był inspirowany przez funkcje Visual Studio dla specjalistów baz danych. Jeśli chcesz narzędzie open source z tych samych funkcji, spróbuj tego: http://dbsourcetools.codeplex.com/ Baw - Nathan.

Odpowiedział 07/07/2009 o 14:26
źródło użytkownik

głosy
6

Scott Ambler produkuje wielką serię artykułów (i współautorem książki ) na refaktoringu bazy danych, z myślą, że należy zasadniczo stosować zasady i praktyki TDD na utrzymanie schematu. Skonfigurować szereg konstrukcji i sadzeniaków testów jednostkowych danych dla bazy danych. Następnie, zanim cokolwiek zmienić, zmodyfikować / napisać testy, aby odzwierciedlić tę zmianę.

Robiliśmy to na chwilę teraz i wydaje się działać. Pisaliśmy kod, aby wygenerować podstawowe nazwa kolumny i typ danych kontrole w apartamencie testów jednostkowych. Możemy w każdej chwili ponownie uruchomić te testy w celu sprawdzenia, że ​​baza danych w kasie SVN mecze na żywo db aplikacja jest uruchomiona.

Jak się okazuje, programiści czasami dostosować swoją bazę sandbox i zaniedbywania zaktualizować plik schematu w SVN. Następnie kod zależy od zmiany db, który nie został zgłoszony do odprawy. Tego rodzaju błąd może być irytująco trudne do spostrzeżenia, lecz zestaw testowy będzie go podnieść od razu. Jest to szczególnie miłe, jeśli masz to wbudowane w większej Continuous Integration planu.

Odpowiedział 29/08/2008 o 05:51
źródło użytkownik

głosy
6

Zrzucić swój schemat do pliku i dodać go do kontroli źródła. Wtedy prosty diff pokaże, co się zmieniło.

Odpowiedział 06/08/2008 o 17:59
źródło użytkownik

głosy
5

K. Scott Allen ma przyzwoitą artykuł lub dwa na schemacie wersjonowanie, który wykorzystuje koncepcję przyrostowych aktualizacji skryptów / migracje wymieniony w innych odpowiedzi tutaj; zobacz http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx .

Odpowiedział 29/08/2008 o 06:11
źródło użytkownik

głosy
5

Jeśli używasz C #, rzucić okiem na poddźwiękowego bardzo użyteczne narzędzie ORM, ale także generuje skrypt SQL, aby odtworzył swój schemat i \ lub danych. Skrypty te mogą być następnie wprowadzone do kontroli źródła.

http://subsonicproject.com/

Odpowiedział 04/08/2008 o 23:47
źródło użytkownik

głosy
5

To trochę niski tech, i nie może być lepszym rozwiązaniem tam, ale można po prostu zapisać schemat w skrypcie SQL, które mogą być uruchamiane w celu utworzenia bazy danych. Myślę, że można wykonać polecenie do wygenerowania tego skryptu, ale nie znam komendy niestety.

Następnie popełnić skrypt do kontroli źródła wraz z kodem, który działa na nim. Kiedy trzeba zmienić schemat wraz z kodem, skrypt można sprawdzić w wraz z kodem, który wymaga zmienionego schematu. Następnie diffs na skrypcie wskaże dyferencjału na temat zmiany schematu.

Z tego skryptu, można zintegrować go z DBUnit lub jakiejś kompilacji skryptu, więc wydaje się to mogło zmieścić się w swoim już zautomatyzowanych procesów.

Odpowiedział 04/08/2008 o 23:28
źródło użytkownik

głosy
4

Użyłem następującą strukturę projektu bazy danych w Visual Studio dla kilku projektów i to działało całkiem dobrze:

Baza danych

Zmiany Skrypty

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

Tworzenie skryptów

sprocs

Funkcje

widoki

Nasz system build następnie aktualizuje bazę danych z jednej wersji do następnego wykonując skrypty w następującej kolejności:

1.PreDeploy.sql

2.SchemaChanges.sql

Zawartość Utwórz folder Scripts

2.DataChanges.sql

3.Permissions.sql

Każdy sprawdza programistów w ich zmian dla danego błędu / funkcję, dołączając swój kod na końcu każdego pliku. Po głównym wersja jest kompletna i rozgałęzione w kontroli źródła, zawartość tych plików .sql w folderze Scripts Zmiany są usuwane.

Odpowiedział 08/08/2008 o 19:31
źródło użytkownik

głosy
4

Używamy bardzo proste, ale jeszcze skutecznego rozwiązania.

W nowych instalacjach, mamy plik metadata.sql w repozytorium, które posiada wszystkie schematu DB, a następnie w procesie budowania używamy tego pliku do generowania bazy danych.

Aktualizacji, dodamy aktualizacje w oprogramowaniu sztywno. Trzymamy to ustalony, ponieważ nie lubimy rozwiązywania problemów zanim to naprawdę jest problem, i tego typu rzeczy nie okazać się problemem tak daleko.

Tak więc w naszym oprogramowaniu mamy coś takiego:

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

Ten kod sprawdza, czy baza danych jest w wersji 1 (który jest przechowywany w tabeli utworzonej automatycznie), jeśli jest nieaktualne, a następnie polecenie jest wykonywane.

Aby zaktualizować metadata.sql w repozytorium, możemy uruchomić ten uaktualnia lokalnie, a następnie wyodrębnić pełną metadane bazy danych.

Jedyną rzeczą, która dzieje się tak często, jest zapomnieć popełnienia ten metadata.sql, ale nie jest to poważny problem, ponieważ jego łatwe do sprawdzenia na proces budowy, a także jedyną rzeczą, która może się zdarzyć jest, aby nowa instalacja z przestarzała baza danych i przenieśli go na pierwszym użyciu.

Również my nie obsługują umniejsza, ale to jest zgodne z projektem, jeśli coś łamie się na aktualizację, że przywrócił poprzednią wersję i naprawić aktualizację przed ponowną próbą.

Odpowiedział 08/08/2008 o 19:21
źródło użytkownik

głosy
3

Tworzę folderów nazwanych wersji kompilacji i umieścić aktualizacji i downgrade skrypty tam. Na przykład można 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 aktualizację lub obniżyć bazę danych pomiędzy wersjami.

Jeżeli klient lub klient zadzwonić z problemem z wersji 1.0.1 i 1.0.2 używasz, przynosząc do bazy danych z powrotem do swojej wersji nie będzie problemu.

W swojej bazie danych, należy utworzyć tabelę o nazwie „schemat”, gdzie można umieścić w bieżącej wersji bazy danych. Następnie napisanie programu, który można uaktualnić lub downgrade bazę dla ciebie jest łatwe.

Podobnie jak Joey powiedział, że jeśli jesteś w świecie Rails, użyj migracje. :)

Odpowiedział 05/08/2008 o 05:36
źródło użytkownik

głosy
2

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

Odpowiedział 19/01/2012 o 02:52
źródło użytkownik

głosy
2

Lubię sposób w jaki Yii obsługuje migrację bazy danych. Migracja jest w zasadzie skrypt PHP realizacji CDbMigration. CDbMigrationokreśla się upmetodę, która zawiera logikę migracji. Jest również możliwe do wdrożenia downmetody wspierania odwrócenie migracji. Alternatywnie, safeUplub safeDownmogą być wykorzystane, aby upewnić się, że migracja odbywa się w kontekście transakcji.

Narzędzie wiersza polecenia Yii yiiczawiera wsparcie dla tworzenia i wykonywania migracje. Migracji można stosować lub odwrócone, albo jeden po drugim lub w serii. Tworzenie wyniki migracji w kodzie dla klasy PHP wykonawczego CDbMigration, o nazwie jednoznacznie na podstawie znacznika czasu i nazwą migracji określonym przez użytkownika. Wszystkie migracje, które zostały wcześniej zastosowane do bazy danych są przechowywane w tabeli migracji.

Aby uzyskać więcej informacji, zobacz migracji bazy danych artykuł z podręcznika.

Odpowiedział 25/06/2011 o 14:18
źródło użytkownik

głosy
2

migracje IMHO mają ogromny problem:

Aktualizacja z jednej wersji do innej działa dobrze, ale robi nową instalację danej wersji może trwać wiecznie, jeśli masz setki tabel i długą historię zmian (tak jak my).

Uruchamiając całą historię delt od podstawowej aż do obecnej wersji (dla setek baz danych klientów) może trwać bardzo długo.

Odpowiedział 12/03/2011 o 15:15
źródło użytkownik

głosy
2

Toad for MySQL ma funkcję o nazwie schematu porównać, który pozwala synchronizować 2 baz danych. Jest to najlepsze narzędzie Użyłem tej pory.

Odpowiedział 05/02/2011 o 12:08
źródło użytkownik

głosy
2

Polecam przy użyciu Ant (cross platform) dla „scripting” strony (ponieważ może rozmawiać z każdym praktycznie db tam poprzez JDBC) i Subversion dla repozytorium źródłowego. Mrówka będzie alow do „kopię zapasową” swoją db do lokalnych plików, przed dokonaniem zmiany. 1. zapasowej istniejącego schematu db złożyć poprzez Ant 2. kontroli wersji Subversion do repozytorium przez Ant 3. wysyłać nowe SQL DB poprzez Ant

Odpowiedział 17/09/2008 o 17:54
źródło użytkownik

głosy
2

Dla mojego obecnego projektu PHP używamy pojęcia szyn migracje i mamy katalog migracje w którym przechowywać pliki tytuł „migration_XX.sql”, gdzie XX oznacza numer migracji. Obecnie te pliki są tworzone przez strony jako aktualizacje są wykonane, ale ich tworzenie można łatwo modyfikować.

Następnie mamy skrypt o nazwie „Migration_watcher”, który, jak jesteśmy w pre-alpha, obecnie działa na każdej stronie obciążenia i sprawdza, czy jest nowy plik migration_XX.sql gdzie XX jest większa od bieżącej wersji migracji. Jeśli tak to uruchamia wszystkie pliki migration_XX.sql do największej liczby przeciwko bazy danych i voila! Zmiany schematu są zautomatyzowane.

Jeśli potrzebna zdolność, aby przywrócić system musiałby dużo szczypanie, ale to proste i działa bardzo dobrze dla naszej dość mały zespół do tej pory.

Odpowiedział 23/08/2008 o 13:58
źródło użytkownik

głosy
0

Jest wiersza polecenia mysql-diff narzędzie, które porównuje schematów bazy danych, gdzie Schemat może być na żywo w bazie SQL lub skrypt na dysku. To jest dobre dla większości zadań migracji schematu.

Odpowiedział 04/11/2009 o 20:43
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more