Jak wersjonujesz schemat bazy danych? [Zamknięte]

Jak przygotowujesz swoje delty SQL? czy ręcznie zapisujesz każdy kod SQL zmieniający schemat w folderze delta, czy masz jakiś rodzaj automatycznego procesu porównywania?

Interesują mnie konwencje dotyczące wersjonowania schematu bazy danych wraz z kodem źródłowym. Być może hak przed zatwierdzeniem, który różni schemat?

Jakie są też opcje różnicowania delt oprócz DbDeploy ?

EDYCJA: widząc odpowiedzi, chciałbym wyjaśnić, że znam standardowy schemat przeprowadzania migracji bazy danych za pomocą delt. Moje pytanie dotyczy tworzenia samych delt, najlepiej automatycznie.

Ponadto wersjonowanie dotyczy PHP i MySQL, jeśli ma to znaczenie. (Nie używaj rozwiązań Ruby).

Widzieć

Czy istnieje system kontroli wersji dla zmian struktury bazy danych?

Jak mogę wersjonować moją bazę danych MS SQL w SVN?

i artykuł Jeffa

Uzyskaj bazę danych pod kontrolą wersji

Czuję twój ból i chciałbym, żeby była lepsza odpowiedź. To może być bliższe temu, czego szukałeś.

Mechanizmy śledzenia zmian schematu bazy danych

Generalnie czuję, że nie ma adekwatnego, akceptowanego rozwiązania tego problemu i stawiam własne w tej dziedzinie.

Możesz rzucić okiem na inny, podobny wątek: Jak mogę wersjonować moją bazę danych MS SQL w SVN? .

Jeśli nadal szukasz opcji: spójrz na projektanta neXtep. Jest to bezpłatne środowisko programistyczne baz danych GPL oparte na koncepcji kontroli wersji. W środowisku zawsze pracujesz z wersjonowanymi jednostkami i możesz skupić się na rozwoju modelu danych. Po zakończeniu wydania silnik generowania kodu SQL podłączony do systemu kontroli wersji może wygenerować dowolną potrzebną różnicę między 2 wersjami i zaoferuje Ci pewien mechanizm dostarczania, jeśli zajdzie taka potrzeba.

Między innymi możesz synchronizować i odwracać synchronizację bazy danych podczas opracowywania, tworzyć diagramy modeli danych, wykonywać zapytania do bazy danych za pomocą zintegrowanych klientów SQL itp.

Zajrzyj na wiki, aby uzyskać więcej informacji: http://www.nextep-softwares.com/wiki

Obecnie obsługuje Oracle, MySql i PostgreSql i jest w Javie, więc produkt działa w systemach Windows, Linux i Mac.

Dbam o to, aby zmiany schematu były zawsze addytywne. Dlatego nie usuwam kolumn i tabel, ponieważ spowodowałoby to zniszczenie danych i nie można ich później przywrócić. W ten sposób kod korzystający z bazy danych można przywrócić bez utraty danych lub funkcjonalności.

Mam skrypt migracji, który zawiera instrukcje, które tworzą tabele i kolumny, jeśli jeszcze nie istnieją, i wypełnia je danymi.

Skrypt migracji jest uruchamiany za każdym razem, gdy kod produkcyjny jest aktualizowany i po nowych instalacjach.

Kiedy chcę coś upuścić, robię to, usuwając je ze skryptu instalacyjnego bazy danych i skryptu migracji, aby te przestarzałe elementy schematu były stopniowo wycofywane w nowych instalacjach. Wadą jest to, że nowe instalacje nie mogą przejść na starszą wersję przed instalacją.

I oczywiście wykonuję pliki DDL za pomocą tych skryptów i nigdy bezpośrednio w bazie danych, aby zachować synchronizację.

Nie zarządzam deltami. Wprowadzam zmiany w głównej bazie danych i mam narzędzie, które tworzy skrypt budowania oparty na języku XML na podstawie głównej bazy danych.

Kiedy nadchodzi czas na aktualizację istniejącej bazy danych, mam program, który używa skryptu budowania opartego na XML do tworzenia nowej bazy danych i samych tabel. Następnie kopiuję dane ze starej bazy danych za pomocą INSERT INTO x SELECT FROM y, a następnie stosuję wszystkie indeksy, ograniczenia i wyzwalacze.

Nowe tabele, nowe kolumny, usunięte kolumny są obsługiwane automatycznie i dzięki kilku drobnym sztuczkom dostosowującym procedurę kopiowania mogę obsługiwać zmiany nazw kolumn, zmiany typu kolumn i inne podstawowe refaktoryzacje.

Nie polecałbym tego rozwiązania w przypadku bazy danych z ogromną ilością danych, ale regularnie aktualizuję bazę danych, która ma ponad 1 GB z 400 tabelami.

Nie wspomniałeś, którego RDBMS używasz, ale jeśli jest to MS SQL Server, Red-Gate's SQL Compare było dla nas nieodzowne przy tworzeniu różnic między skryptami do tworzenia obiektów.

Nie jestem osobą, która chce się rozwalić, ale opracowałem wewnętrzną aplikację internetową do śledzenia zmian w schematach bazy danych i tworzenia wersjonowanych skryptów aktualizacji.

To narzędzie nazywa się Brazil i jest teraz open source na licencji MIT. Brazylia jest oparta na Ruby / Ruby on Rails i obsługuje wdrażanie zmian w dowolnej bazie danych Ruby DBI obsługiwanej przez (MySQL, ODBC, Oracle, Postgres, SQLite).

Planowana jest obsługa wprowadzania aktualizacji skryptów do kontroli wersji.

http://bitbucket.org/idler/mmp - narzędzie do wersjonowania schematów dla mysql, napisane w PHP

Eksportujemy dane do formatu przenośnego (przy użyciu naszego zestawu narzędzi), a następnie importujemy je do nowego schematu. nie ma potrzeby korzystania z delta SQL. Wysoce rekomendowane.

Używam bazy danych Firebird do większości programów i używam FlameRobin narzędzia administracyjnego . Ma fajną opcję rejestrowania wszystkich zmian. Może rejestrować wszystko do jednego dużego pliku lub jednego pliku na zmianę w bazie danych. Używam tej drugiej opcji, a następnie przechowuję każdy skrypt w oprogramowaniu do kontroli wersji - wcześniej używałem Subversion, teraz używam Gita.

Zakładam, że możesz znaleźć narzędzie MySQL, które ma taką samą funkcję rejestrowania, jak FlameRobin dla Firebird.

W jednej z tabel bazy danych przechowuję numer wersji struktury bazy danych, dzięki czemu mogę łatwo zaktualizować dowolną bazę danych. Napisałem również prosty skrypt PHP, który wykonuje te skrypty SQL jeden po drugim w dowolnej docelowej bazie danych (ścieżka bazy danych i nazwa użytkownika / hasło są dostarczane w wierszu poleceń).

Istnieje również opcja rejestrowania wszystkich instrukcji DML (wstawianie, aktualizowanie, usuwanie) i aktywuję ją podczas modyfikowania niektórych „domyślnych” danych, które zawiera każda baza danych.

Napisałem niezłą białą księgę o tym, jak szczegółowo to wszystko robię. Możesz pobrać artykuł w formacie .pdf wraz ze skryptami demonstracyjnymi PHP stąd .

Opracowałem również zestaw skryptów PHP, w których programiści mogą przesyłać swoje skrypty deltasql do centralnego repozytorium.

W jednej z tabel bazy danych (o nazwie TBSYNCHRONIZE) przechowuję numer wersji ostatnio wykonanego skryptu, dzięki czemu mogę łatwo zaktualizować dowolną bazę danych za pomocą interfejsu internetowego lub klienta opracowanego specjalnie dla Eclipse.

Interfejs sieciowy umożliwia zarządzanie kilkoma projektami. Obsługuje również „oddziały” bazy danych.

Możesz przetestować aplikację pod adresem http://www.gpu-grid.net/deltasql (jeśli logujesz się jako administrator z hasłem testdbsync). Aplikacja jest open source i można ją pobrać tutaj: http://sourceforge.net/projects/deltasql

deltasql jest używany produktywnie w Szwajcarii i Indiach oraz jest popularny w Japonii.

Kilka miesięcy temu szukałem narzędzia do wersjonowania schematu MySQL. Znalazłem wiele przydatnych narzędzi, takich jak migracja Doctrine, migracja RoR, niektóre narzędzia napisane w Javie i Pythonie.

Ale żaden z nich nie spełnił moich wymagań.

Moje wymagania:

1. Brak wymagań, wyłącz PHP i MySQL
2. Brak plików konfiguracyjnych schematu, takich jak schema.yml w Doctrine
3. Potrafi odczytać aktualny schemat z połączenia i utworzyć nowy skrypt migracji, niż reprezentować identyczny schemat w innych instalacjach aplikacji.

Zacząłem pisać swoje narzędzie do migracji, a dziś mam wersję beta.

Spróbuj, jeśli interesuje Cię ten temat. Proszę o przesyłanie mi przyszłych próśb i raportów o błędach.

Kod źródłowy: bitbucket.org/idler/mmp/src Przegląd w języku angielskim: bitbucket.org/idler/mmp/wiki/Home Przegląd w języku rosyjskim: antonoff.info/development/mysql-migration-with-php-project

Używam http://code.google.com/p/oracle-ddl2svn/

Ten temat też mnie interesuje.

Jest kilka dyskusji na ten temat na wiki Django .

Co ciekawe, wygląda na to, że CakePHP ma wbudowane przechowywanie wersji schematu za pomocą samego cake schema generatepolecenia.

Dla MySQL

Kiedy wyląduję na nowym DB:

Najpierw sprawdzam strukturę:

mysqldump --no-data --skip-comments --skip-extended-insert -h __DB_HOSTNAME__ -u __DB_USERNAME__ -p __DB1_NAME__ | sed 's/ AUTO_INCREMENT=[0-9]*//g' > FILENAME_1.sql
mysqldump --no-data --skip-comments --skip-extended-insert -h __DB_HOSTNAME__ -u __DB_USERNAME__ -p __DB2_NAME__ | sed 's/ AUTO_INCREMENT=[0-9]*//g' > FILENAME_2.sql
diff FILENAME_1.sql FILENAME_2.sql > DIFF_FILENAME.txt
cat DIFF_FILENAME.txt | less

Dzięki użytkownikom stackoverflow mogłem napisać ten szybki skrypt, aby znaleźć różnice w strukturze.

src: https://stackoverflow.com/a/8718572/4457531 i https://stackoverflow.com/a/26328331/4457531

W drugim kroku sprawdzam dane, tabela po tabeli za pomocą mysqldiff. To trochę archaiczne, ale pętla php oparta na danych z information_schemapewnością działa

Do wersjonowania używam tego samego sposobu, ale formatuję skrypt aktualizacji SQL (do aktualizacji lub wycofania) z wynikami różnic i używam konwencji numeru wersji (z kilkoma modyfikacjami numer wersji wygląda jak adres IP) .

initial version : 1.0.0
                  ^ ^ ^
                  | | |
structure change: - | |
datas added: -------- |
datas updated: --------

Używam ścisłego wersjonowania schematu bazy danych (śledzonego w osobnej tabeli). Skrypty są przechowywane w kontroli wersji, ale wszystkie sprawdzają bieżącą wersję schematu przed wprowadzeniem jakichkolwiek zmian.

Oto pełna implementacja dla SQL Server (w razie potrzeby to samo rozwiązanie można opracować dla MySQL): Jak utrzymać wersję schematu bazy danych SQL Server

Po długim badaniu stwierdziłem, że istnieją narzędzia innych firm lub typy projektów Visual Studio, które mnie nie satysfakcjonują lub po prostu blogują o teorii, ale bez implementacji. Wdrożyłem więc działający system, który jest używany przez prawie rok i wyjaśniłem tutaj:

http://nalgorithm.com/2015/11/09/database-versioning-part-1/

w zależności od zainteresowania, będę dalej pisać.