# Datenbank-Migrationen

Migrationen liegen hier als `.sql`-Dateien, benannt nach dem Schema:

```
0001_kurze_beschreibung.sql
0002_naechste_aenderung.sql
```

`update.sh` ruft `migrations/run_migrations.php <pfad-zur-config.php>` auf. Das Skript:

- legt bei Bedarf die Tabelle `schema_migrations` an (Spalte `filename` als Primary Key), die protokolliert, welche Dateinamen bereits angewendet wurden
- führt alle noch nicht angewendeten `.sql`-Dateien in Dateinamen-Reihenfolge aus
- bricht beim ersten Fehler sofort ab (die fehlgeschlagene Datei wird NICHT als angewendet markiert, alle vorherigen bleiben es)

## Regeln für neue Migrationen

- Immer die nächste freie, vierstellige Nummer verwenden (`0003_...`). Eine bereits vergebene Nummer nie wiederverwenden, eine bereits angewendete Datei nachträglich nicht mehr ändern (neue Migration statt Änderung der alten).
- So schreiben, dass sie **keine Breaking Changes** verursachen, z. B.:
  - `CREATE TABLE IF NOT EXISTS ...` statt `CREATE TABLE ...`
  - Neue Spalten nullable oder mit `DEFAULT` anlegen, statt bestehende `NOT NULL`-Constraints nachträglich zu erzwingen
  - Kein `DROP TABLE` / `DROP COLUMN` ohne vorherige Rücksprache
- Migrationen möglichst idempotent halten (`IF NOT EXISTS`), damit ein erneuter Lauf nach einem Teilfehler nicht sofort wieder bricht.

## Historie

`init.sql` (Ausgangsschema für Neuinstallationen) und `update.sql` (bereits manuell eingespieltes Aktien-Modul) liegen bewusst außerhalb dieses Verzeichnisses, da beide bereits auf allen bekannten Servern produktiv sind. Ab jetzt werden neue Schema-Änderungen ausschließlich als nummerierte Migration hier abgelegt.

## Hinweis

`run_migrations.php` bindet die produktive `config.php` per `require` ein, um die bestehende `$pdo`-Verbindung wiederzuverwenden. Da `config.php` `session_start()` aufruft, legt der CLI-Lauf dabei eine kurzlebige, ungenutzte Session-Datei an — das ist unschädlich, aber erwähnenswert.