Odpowiedź.

Historia zagadnienia
Praca nad dużymi projektami wymaga, aby struktura bazy danych rozwijała się równolegle z kodem aplikacji. Bez programowego zarządzania wersjami zmian schematu (dodawania, usuwania i modyfikacji tabel, indeksów, kluczy) zespół szybko traci synchronizację, rośnie ryzyko utraty zmian, błędów migracji oraz komplikacji przy wycofywaniu lub reprodukcji błędów.

Problem
Tradycyjne podejście — ręczna modyfikacja bazy danych przez skrypty SQL — prowadzi do niejawnej kolejności wykonywania zmian, trudności w wycofywaniu, rozbieżności wersji między środowiskami (dev, test, prod). Bez wspólnego narzędzia do przechowywania migracji trudno zrozumieć, kto, kiedy i dlaczego zmienił schemat.

Rozwiązanie
Do tego zadania używa się systemów migracji schematu oraz praktyk versioningu bazy danych. Zastosowanie narzędzi (np. Liquibase, Flyway, Alembic dla różnych DBMS) pozwala przechowywać skrypty SQL zmian schematu bezpośrednio w systemie kontroli wersji (git), formować ścisłą sekwencję migracji oraz automatyzować aktualizacje schematu we wszystkich środowiskach.

Przykład kodu (migracja przez Flyway):

-- V002__dodaj_kolumne_email.sql
ALTER TABLE users ADD COLUMN email VARCHAR(255) NOT NULL;

Integracja Flyway (np. dla Javy):

Flyway.configure().dataSource(url, user, pass).load().migrate();

Kluczowe cechy:

• Umożliwia wszystkim programistom „widzenie” i stosowanie tej samej sekwencji zmian.
• Łatwo „wycofać” lub przywrócić dowolną wersję schematu.
• Cała historia zmian schematu jest przejrzysta i może być przeglądana razem z logiką biznesową.

Pytania z haczykami.

Czy można przechować „stan pierwotny” schematu (snapshot) zamiast migracji? Na pierwszy rzut oka „eksport” całego schematu jest prostszy niż migracje. Ale wtedy wystąpią problemy z wycofywaniem, przywracaniem pośrednich stanów i łączeniem zmian z różnych gałęzi. Migracje pozwalają stosować tylko nowe zmiany w sposób sekwencyjny i w odpowiedniej kolejności.

Czy trzeba ręcznie synchronizować migracje między różnymi środowiskami? Nie, nowoczesne systemy szanują wersjonowanie i same stosują tylko te migracje, które jeszcze nie były w bazie. Kluczowe jest nie ręczne synchronizowanie, lecz automatyczne stosowanie migracji podczas wdrożenia.

Czy wystarczą tylko skrypty SQL migracji, czy warto przechowywać coś jeszcze? Dobrą praktyką jest przechowywanie oprócz skryptów SQL ich opisów (cel, autor, data), a także testów-walidatorów nowych zmian strukturalnych, aby zautomatyzować kontrolę jakości migracji.

Typowe błędy i antywzorce

• Stosowanie „ręcznych” zmian niezależnie od migracji: prowadzi do rozbieżności środowisk.
• Edytowanie istniejących migracji „z perspektywy czasu” — grozi zniszczeniem historii i nieidempotentnymi działaniami.
• Ignorowanie migracji odwracalnych (down).

Przykład z życia

Negatywny przypadek

Projekt korzystał z normalnych zrzutów schematów i „ręcznego” stosowania zmian przez programistów. Po uruchomieniu aktualizacji klient zauważył, że część nowych kolumn w produkcyjnej bazie się nie pojawiła, a część indeksów podwajała się po każdej próbie aktualizacji schematu.

Plusy:
Szybko dla bardzo małych projektów.

Minusy:
Trudności z utrzymywaniem; nie można zrozumieć, co dokładnie zostało zmienione i przez kogo; niemożność wycofywania; różne środowiska się rozjeżdżają.

Pozytywny przypadek

Zespół zintegrował Flyway, wszystkie zmiany strukturalne są wprowadzane przez migracje z recenzją kodu, wycofanie dowolnych wersji zajmowało zaledwie kilka minut, łatwo prowadzić testy i kontrole we wszystkich środowiskach.

Plusy:
Automatyzacja, historia, małe prawdopodobieństwo błędów przy wdrożeniu.

Minusy:
Potrzeba nieco dłuższego dokumentowania każdej zmiany struktury.