Schema Migration — essentie, typen en hulpmiddelen voor databankschema-migratie

Wat is Schema Migration

Schema Migration is de praktijk van het beheren van wijzigingen in de databankstructuur via versiebeheerde bestanden die opeenvolgend op verschillende omgevingen worden toegepast. Elk bestand bevat een reeks SQL-opdrachten: het aanmaken van een tabel, het toevoegen van een kolom, het wijzigen van een index of het bijwerken van beperkingen. Het migratieprogramma houdt toegepaste versies bij en garandeert dat elke wijziging precies eenmaal wordt uitgevoerd.

In tegenstelling tot Data Migration, die de inhoud van tabellen verplaatst, beheert Schema Migration alleen de structuur — DDL-bewerkingen. Dit is een fundamenteel verschil: Schema Migration werkt vóór Data Migration, maakt het doelschema aan, waarna Data Migration het met gegevens vult. Volgens Redgate (2024) heeft 62% van de incidenten in productiedatabanken te maken met handmatige schemawijzigingen zonder migratiescripts.

Versiebeheer van migraties

Elke Schema Migration krijgt een unieke identificatie — meestal een versie (V1, V2) of een tijdstempel. Het hulpmiddel slaat in een speciale tabel (flyway_schema_history, alembic_version) de lijst van toegepaste migraties op. Bij het opstarten vergelijkt het de lijst met bestanden in het classpath en past alleen nieuwe toe. Idempotentie is de belangrijkste eigenschap: herhaaldelijk uitvoeren veroorzaakt geen bijwerkingen.

Soorten schemawijzigingen

Typische Schema Migration-bewerkingen: het aanmaken van tabellen (CREATE TABLE), het toevoegen van kolommen (ALTER TABLE ADD COLUMN), het wijzigen van typen, het aanmaken van indexen, het toevoegen van externe sleutels en het bijwerken van sequenties. Complexere migraties omvatten het hernoemen van kolommen met behoud van gegevens, het splitsen van een tabel in meerdere delen en het repliceren van een schema naar shards.

Waarom is databankschema-migratie nodig

Zonder Schema Migration wijzigen ontwikkelaars de databank handmatig — ze schrijven DDL in de console, voegen kolommen toe in de dev-omgeving en kopiëren ze uit het geheugen naar staging. Resultaat: schema-afwijkingen tussen omgevingen, verlies van wijzigingen bij implementatie en defecte migraties in productie. Schema Migration lost drie belangrijke problemen op: consistentie, reproduceerbaarheid en auditing.

Consistentie tussen omgevingen

Wanneer de databankstructuur in code is beschreven, is deze identiek in dev, staging en productie. Een ontwikkelaar kan niet vergeten een wijziging toe te passen — het hulpmiddel voert alle gemiste migraties opeenvolgend uit. Als in productie een kolom ontbreekt maar de code deze vereist, crasht de applicatie met een foutmelding. Automatische controle elimineert dit scenario.

Reproduceerbaarheid voor nieuwe ontwikkelaars

Een nieuw teamlid voert flyway migrate uit en krijgt binnen enkele seconden het actuele schema — zonder dump uit productie en handmatige DDL-query's. Dit is vooral belangrijk bij een microservice-architectuur, waarbij elke service zijn eigen databank heeft en het schema uit tientallen migraties is opgebouwd. Volledige reproduceerbaarheid verkort de inwerktijd van dagen tot minuten.

Auditing van wijzigingen

Elke Schema Migration wordt samen met de applicatiecode in het versiebeheersysteem opgeslagen. U kunt een Pull Request openen, de exacte SQL-opdrachten voor de schemawijziging bekijken en een code review uitvoeren. Bij een incident is eenvoudig te bepalen welke migratie als laatste is toegepast en wie de auteur is. Git-geschiedenis biedt een volledig spoor van databankwijzigingen gedurende de hele looptijd van het project.

Hulpmiddelen voor schemamigratie

Er zijn tientallen Schema Migration-hulpmiddelen op de markt voor verschillende talen en platformen. De keuze hangt af van de technologiestack, het formaat van de migratiebeschrijving en de vereisten voor terugdraaien. Laten we de belangrijkste categorieën en populaire hulpmiddelen bekijken.

Hoe kiest u een hulpmiddel

Voor Java/Kotlin-stacks — Flyway als het lichtste en meest voorspelbare hulpmiddel. Voor projecten met frequent terugdraaien — Liquibase, waarbij rollback architectonisch is ingebouwd. Voor Python/Django — Alembic als het standaard SQLAlchemy-hulpmiddel. Voor startups zonder DevOps-ingenieur — kies het hulpmiddel met de minste configuratie: Flyway vereist alleen een scriptbestand en de opdracht migrate.

Commerciële oplossingen

Naast open-source hulpmiddelen bestaan er commerciële oplossingen: Redgate SQL Change Automation, Datical DB en DBmaestro. Deze bieden visuele schemavergelijking, automatische conflictoplossing en integratie met CI/CD-pijplijnen. Voor de meeste projecten dekken Flyway of Alembic echter 100% van de behoeften zonder extra licenties.

Migratie met Flyway

Laten we een praktisch voorbeeld van Schema Migration in Kotlin met Flyway bekijken. We maken een migratie die de tabel orders toevoegt aan de PostgreSQL-databank. Flyway maakt automatisch de tabel flyway_schema_history aan en houdt toegepaste versies bij.

-- 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)
);

Flyway verbinden in een Kotlin-project via de dataSource-configuratie. Na configuratie past de opdracht flyway:migrate alle nieuwe migraties uit het classpath toe.

// FlywayConfig.kt — Flyway-configuratie in 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 voor Python-projecten

Alembic is een Schema Migration-hulpmiddel voor Python, gebouwd op SQLAlchemy. Het belangrijkste kenmerk is het automatisch genereren van scripts op basis van vergelijking van het SQLAlchemy-model met het huidige databankschema. Alembic is geschikt voor Django-, FastAPI- en Flask-projecten.

Initialisatie en migratie aanmaken

Na initialisatie (alembic init alembic) en configuratie van de connection string, scant de opdracht alembic revision --autogenerate de SQLAlchemy-modellen en genereert een migratiescript. De ontwikkelaar hoeft alleen de gegenereerde code te controleren en deze toe te passen via alembic upgrade head. Autogenerate bespaart uren handmatig DDL-schrijven.

# models.py — SQLAlchemy-model voor automatische generatie
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)

Beste praktijken voor schemamigratie

Ervaren teams hebben een reeks Schema Migration-regels ontwikkeld die het risico op fouten verminderen en het debuggen vereenvoudigen. Het naleven van deze praktijken is een teken van volwassen technische cultuur. Vijf kernregels omvatten het ontwerpen, testen en implementeren van migraties.

Eén migratie — één wijziging

Elke Schema Migration moet precies één logische wijziging doorvoeren: een tabel aanmaken, een kolom toevoegen of een index wijzigen. Het mengen van meerdere bewerkingen in één migratie maakt terugdraaien moeilijk — als de tweede bewerking faalt, is de eerste al toegepast en moet deze apart worden teruggedraaid. Kleine stappen vormen de basis van betrouwbare migraties.

Gepubliceerde migraties nooit bewerken

Nadat een migratie in productie is toegepast, mag deze niet worden gewijzigd — er moet alleen een nieuwe migratie worden gemaakt die het probleem oplost. Het bewerken van een gepubliceerde migratie beschadigt de tracker: ontwikkelaars met een andere databank zien een hash-mismatch. Onveranderlijke migraties garanderen voorspelbaar gedrag in alle omgevingen.

Testen op een kopie van productie

Voordat u Schema Migration in productie toepast, voert u deze uit op een kopie van productiegegevens. Het doel is het controleren van de uitvoeringssnelheid, het optreden van tabelvergrendelingen en de juistheid van wijzigingen. Voor grote tabellen kan ALTER TABLE het schrijven urenlang blokkeren — een test zal dit van tevoren onthullen. Staging met een productiedump is een verplichte stap.

NOT NULL vermijden voor nieuwe kolommen

Een nieuwe kolom zonder standaardwaarde met NOT NULL is een veelvoorkomende oorzaak van migratiefouten. In bestaande records is de waarde NULL en veroorzaakt NOT NULL een foutmelding. Aanbevolen werkwijze: maak de kolom met een standaardwaarde en nullable aan, voeg vervolgens met een aparte migratie NOT NULL toe nadat de gegevens zijn ingevuld.