Schema Migration — podstata, typy a nástroje migrace schémat databází

Co je Schema Migration

Schema Migration je praxe řízení změn struktury databáze prostřednictvím verzovaných souborů, které jsou postupně aplikovány v různých prostředích. Každý soubor obsahuje sadu SQL příkazů: vytvoření tabulky, přidání sloupce, změna indexu nebo aktualizace omezení. Migrační nástroj sleduje aplikované verze a zaručuje, že každá změna je provedena přesně jednou.

Na rozdíl od Data Migration, která přenáší obsah tabulek, Schema Migration spravuje pouze strukturu — operace DDL. To je zásadní rozdíl: Schema Migration pracuje před Data Migration, vytváří cílové schéma, které pak Data Migration naplní daty. Podle Redgate (2024) souvisí 62 % incidentů v produkčních databázích s ručními změnami schématu bez migračních skriptů.

Verzování migrací

Každá Schema Migration získá jedinečný identifikátor — obvykle verzi (V1, V2) nebo časové razítko. Nástroj ukládá do speciální tabulky (flyway_schema_history, alembic_version) seznam aplikovaných migrací. Při spuštění porovná seznam se soubory v classpath a aplikuje pouze nové. Idempotence je klíčová vlastnost: opakované spuštění nezpůsobuje vedlejší účinky.

Typy změn schématu

Typické operace Schema Migration: vytváření tabulek (CREATE TABLE), přidávání sloupců (ALTER TABLE ADD COLUMN), změna typů, vytváření indexů, přidávání cizích klíčů a aktualizace sekvencí. Složitější migrace zahrnují přejmenování sloupců s zachováním dat, rozdělení tabulky na několik částí a replikaci schématu na shardy.

Proč je potřeba migrace schématu databáze

Bez Schema Migration vývojáři ručně mění databázi — píší DDL v konzoli, přidávají sloupce v dev prostředí a kopírují je do stagingu z paměti. Výsledek: odchylka schémat mezi prostředími, ztráta změn při nasazení a poškozené migrace na produkci. Schema Migration řeší tři klíčové problémy: konzistenci, reprodukovatelnost a audit.

Konzistence mezi prostředími

Když je struktura databáze popsána v kódu, je identická v dev, staging a production. Vývojář nemůže zapomenout aplikovat změnu — nástroj provede všechny zmeškané migrace postupně. Pokud na produkci chybí sloupec, ale kód ho vyžaduje — aplikace spadne s chybou. Automatická kontrola tento scénář eliminuje.

Reprodukovatelnost pro nové vývojáře

Nový člen týmu spustí flyway migrate a během několika sekund získá aktuální schéma — bez dumpu z produkce a ručních DDL dotazů. To je obzvláště důležité v mikroslužbové architektuře, kde každá služba má vlastní databázi a schéma se skládá z desítek migrací. Plná reprodukovatelnost zkracuje dobu zapracování z dnů na minuty.

Audit změn

Každá Schema Migration je uložena v systému správy verzí spolu s kódem aplikace. Lze otevřít Pull Request, vidět přesné SQL příkazy změny schématu a provést code review. Při incidentu lze snadno určit, která migrace byla aplikována jako poslední a kdo je jejím autorem. Historie Git poskytuje úplnou stopu změn databáze po celou dobu trvání projektu.

Nástroje pro migraci schémat

Na trhu existují desítky nástrojů Schema Migration pro různé jazyky a platformy. Výběr závisí na technologickém stacku, formátu popisu migrací a požadavcích na rollback. Podívejme se na hlavní kategorie a populární nástroje.

Jak vybrat nástroj

Pro Java/Kotlin stacky — Flyway jako nejlehčí a nejpředvídatelnější. Pro projekty s častým rollbackem — Liquibase, který má rollback architektonicky vestavěný. Pro Python/Django — Alembic jako standardní nástroj SQLAlchemy. Pro startupy bez DevOps inženýra — vyberte nástroj s nejmenší konfigurací: Flyway vyžaduje pouze soubor se skriptem a příkaz migrate.

Komerční řešení

Kromě open-source nástrojů existují komerční řešení: Redgate SQL Change Automation, Datical DB a DBmaestro. Poskytují vizuální porovnání schémat, automatické řešení konfliktů a integraci s CI/CD pipeline. Pro většinu projektů však Flyway nebo Alembic pokrývají 100 % potřeb bez dalších licencí.

Migrace s Flyway

Podívejme se na praktický příklad Schema Migration v Kotlin s Flyway. Vytvoříme migraci, která přidá tabulku orders do databáze PostgreSQL. Flyway automaticky vytvoří tabulku flyway_schema_history a sleduje aplikované verze.

-- V1__Create_Orders_Table.sql
CREATE TABLE orders (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id         UUID NOT NULL,
    total_amount    DECIMAL(10,2) NOT NULL,
    currency        VARCHAR(3) NOT NULL DEFAULT 'USD',
    status          VARCHAR(20) NOT NULL DEFAULT 'pending',
    created_at     TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id)
);

Připojení Flyway v Kotlin projektu přes konfiguraci dataSource. Po konfiguraci příkaz flyway:migrate aplikuje všechny nové migrace z classpath.

// FlywayConfig.kt — Konfigurace Flyway v Spring Boot
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import org.flywaydb.core.Flyway

@Configuration
class FlywayConfig {
    @Bean
    fun flyway(dataSource: DataSource): Flyway {
        return Flyway.configure()
            .dataSource(dataSource)
            .locations("classpath:db/migration")
            .baselineOnMigrate(true)
            .load()
    }
}

Alembic pro Python projekty

Alembic je nástroj Schema Migration pro Python, postavený na SQLAlchemy. Jeho klíčovou vlastností je auto-generace skriptů na základě porovnání modelu SQLAlchemy s aktuálním schématem databáze. Alembic je vhodný pro projekty v Django, FastAPI a Flask.

Inicializace a vytvoření migrace

Po inicializaci (alembic init alembic) a konfiguraci connection stringu příkaz alembic revision --autogenerate naskenuje modely SQLAlchemy a vygeneruje migrační skript. Vývojáři zbývá zkontrolovat vygenerovaný kód a aplikovat ho přes alembic upgrade head. Autogenerate šetří hodiny ručního psaní DDL.

# models.py — Model SQLAlchemy pro auto-generaci
from sqlalchemy import Column, Integer, String, DateTime, Enum
from sqlalchemy.orm import DeclarativeBase
import enum

class OrderStatus(enum.Enum):
    pending = "pending"
    paid = "paid"
    shipped = "shipped"

class Base(DeclarativeBase):
    pass

class Order(Base):
    __tablename__ = "orders"
    id = Column(Integer, primary_key=True)
    status = Column(Enum(OrderStatus), nullable=False)
    created_at = Column(DateTime, nullable=False)

Nejlepší postupy migrace schémat

Zkušené týmy vyvinuly sadu pravidel Schema Migration, která snižují riziko selhání a zjednodušují ladění. Dodržování těchto postupů je znakem zralé inženýrské kultury. Pět klíčových pravidel pokrývá navrhování, testování a nasazování migrací.

Jedna migrace — jedna změna

Každá Schema Migration by měla provést přesně jednu logickou změnu: vytvořit tabulku, přidat sloupec nebo změnit index. Míchání více operací v jedné migraci komplikuje rollback — pokud druhá operace selže, první už byla aplikována a musí se vracet samostatně. Malé kroky jsou základem spolehlivých migrací.

Nikdy neupravovat publikované migrace

Poté, co byla migrace aplikována na produkci, nelze ji měnit — pouze vytvořit novou, která problém opravuje. Úprava publikované migrace rozbíjí tracker: vývojáři s jinou databází uvidí neshodu hashů. Neměnitelné migrace zaručují předvídatelné chování ve všech prostředích.

Testování na kopii produkce

Před aplikací Schema Migration na produkci ji spusťte na kopii produkčních dat. Cílem je zkontrolovat rychlost provedení, existenci zámků tabulek a správnost změn. U velkých tabulek může ALTER TABLE blokovat zápis na hodiny — test to odhalí včas. Staging s produkčním dumpem je povinný krok.

Vyhnout se NOT NULL u nových sloupců

Nový sloupec bez výchozí hodnoty s NOT NULL — častá příčina selhání migrace. V existujících záznamech bude hodnota NULL a NOT NULL způsobí chybu. Nejlepší postup: vytvořte sloupec s výchozí hodnotou a nullable, pak samostatnou migrací přidejte NOT NULL po naplnění dat.