Obsługa zmian schematu bazy danych podczas wypychania nowych wersji

W czasach intensywnego rozwoju schemat bazy danych zmienia się zarówno szybko, jak i ciągle, a zanim nadejdzie nasza cotygodniowa aktualizacja wersji beta, schemat zmienił się tak bardzo, że jedyną sensowną opcją jest nuke wszystkich tabel, które mogę i skopiuj nowe wersje z mojej bazy danych deweloperów. Oczywiście, to nie zadziała po uruchomieniu, ponieważ nukowanie danych produkcyjnych jest receptą na katastrofę, więc zastanawiałem się, jakie były strategie zarządzania zmianami schematu bazy danych z jednej wersji / wersji do drugiej?

Niektóre znalazłem lub doświadczyłem:

1. Proste nuke-and-dump z jednej bazy danych do drugiej (co teraz robię)
2. Utrzymanie pliku UPDATE.sql z instrukcjami SQL, które uruchamiane są albo przez skrypt, albo ręcznie.
3. Utrzymanie pliku update.php z odpowiednią wartością „db-schema-version” w aktywnej bazie danych

Trzecia opcja wydaje się najbardziej sensowna, ale nadal istnieje możliwość, że źle skonstruowane zapytanie SQL zawiedzie w połowie skryptu, pozostawiając bazę danych w stanie częściowo zaktualizowanym, co wymaga przywrócenia kopii zapasowej.

Wydaje się, że to nie problem, ale tak się dzieje, ponieważ jako zespół używamy phpMyAdmina i nie mogę nawet polegać na sobie, że pamiętam, że skopiowałem wykonaną instrukcję SQL w celu wklejenia do pliku update.php. Po przejściu do innej strony muszę ręcznie napisać instrukcję SQL lub cofnąć moją zmianę i zrobić to ponownie.

Myślę, że to, na co mam nadzieję, to rozwiązanie, które nie ma wpływu na nasz ustalony obieg pracy programistycznej?

Automatyzacja. Automatyzacja. Automatyzacja.

Jesteś na dobrej drodze z jawnym numerem wersji DB, ale poszedłbym o krok dalej i wyraźnie uświadomiłem kodowi dokładnie, z jakim schematem będzie on działał (np. Poprzez zatwierdzenie rzeczywistego skryptu DDL i zlecenie jego aktualizacji ); wtedy w czasie aktualizacji musisz tylko odkryć istniejący schemat za pomocą metadanych bazy danych i INSERT / DROP / ALTER, jeśli to konieczne, bez względu na to, z której wersji na którą aktualizujesz wersję. (Można również zachować jawny numer wersji w samej bazie danych i dostarczyć całą historię schematu za pomocą instalatora, aby nawet nie było potrzebne wykrywanie schematu).

Potencjalne błędy składniowe w skrypcie SQL aktualizacji stanowią problem, ale można go rozwiązać, sprawdzając, czy narzędzie aktualizujące może generować tylko prawidłowe instrukcje DDL. (Formalne proofy prawie nigdy nie są opłacalne przy tworzeniu oprogramowania dla przedsiębiorstw - zbyt duży wysiłek dla zbyt małej pewności - ale uważam, że integralność bazy danych jest jednym z niewielu wyjątków: podstawowy SQL nie jest szczególnie trudnym językiem do formalnego przechwycenia, a korzyścią z ochrona danych produkcyjnych jest tak wielka, że ​​prawie każda jednorazowa praca z góry jest uzasadniona, szczególnie jeśli musi działać w przypadku instalacji nienadzorowanych)

Wersjonowanie schematu bazy danych jest właściwym rozwiązaniem - każda wersja ma tylko jedną zmianę w bazie danych lub przynajmniej zmiany, które można cofnąć w całości. DBDeploy to świetne narzędzie do automatyzacji tego.

Niektóre rzeczy, które nauczyłem się przydatne, to:

1. Zawsze testuj lokalnie swoją zmianę i testuj z nią swój kod, tylko ALTERprzekazanie nie wystarczy
2. Musisz najpierw zsynchronizować, którzy dokonają zmiany - prosta strona wiki, na której możesz „wziąć numer”, działała świetnie dla mojego zespołu.
3. Nie próbuj naprawiać zepsutej zmiany, dodaj nową kontr-zmianę, aby ją zanegować, jest to bezbolesne
4. Twój kod zależy od tych zmian - pamiętaj, aby połączyć problemy w systemie śledzenia błędów ze zmianami DB. Jest to bardzo pomocne w czasie wdrażania.
5. Dołącz zmiany DB do CI - zastosuj zmiany do bazy danych CI przy zatwierdzeniu. Ponadto, jeśli masz jakieś testy korzystające z bazy danych, uruchom je przy zatwierdzeniu.

Ponieważ używasz phpMyAdmin, zakładam, że używasz również MySQL.

Spójrz na diagramy modeli EER w MySQL Workbench. Pomogli mi w utrzymaniu i aktualizacji schematów.

Po pierwsze, możesz zsynchronizować model ze źródłem bazy danych. Tak więc zmiany na diagramie są wypychane jako polecenia ALTER TABLE. Umożliwia to wprowadzanie zmian w schemacie na diagramie, utrzymywanie go zawsze na bieżąco, a także przekazywanie aktualizacji do bazy danych programowania w razie potrzeby.

Po drugie, możesz odtworzyć schemat EER ze źródła bazy danych. Co może być przydatne, wprowadzając zmiany w bazie danych programowania i aktualizując produkcyjną bazę danych, ponieważ obliczy różnice.

Po trzecie, można go użyć do pomocy w utworzeniu kodu SQL, który powinien przejść do pliku „update.sql”.

CONS:

Wyzwalacze i ograniczenia bazy danych stanowią problem z aktualizatorem synchronizacji. Wydaje się, że nie zna właściwej kolejności rzeczy. Ograniczenia klucza obcego często generują błędy, ale można to rozwiązać, edytując generowany przez siebie SQL.

To nie jest narzędzie do migracji danych. Wszelkie zmiany wykraczające poza czysto schemat nadal będą wymagały niestandardowego kodu SQL.

Spójrz na http://south.aeracode.org - jest to biblioteka migracji DB dla Django (frameworku Python), ale:

1. możesz czerpać z tego świetne pomysły (a może nawet znaleźć klon PHP)
2. możesz używać go niezależnie od reszty Django do zarządzania tabelami aplikacji PHP / MySQL.

Może także generować skrypty aktualizacji schematu; przez większość czasu automatycznie obsługuje również zmiany.