Betrieb & Dokumentation › Datenbank-Migrationen (Schema-Pflege)
Datenbank-Migrationen (Schema-Pflege)
BetriebLive✓ Geprüft am Sat Sep 05 2026 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)Wie neue Datenfelder und Tabellen sicher in die laufende Datenbank eingebaut werden, ohne bestehende Daten zu gefährden — jede Programmversion prüft beim Start automatisch, ob neue Spalten/Tabellen fehlen und legt sie nach.
Bild folgt
Bei jedem Start der Anwendung läuft eine feste Prüfliste durch: erst der Grundbestand aller Tabellen von Beginn an, danach eine wachsende Liste ergänzender Nachträge für alles, was seither dazugekommen ist. Beides läuft komplett durch, jedes Mal, ohne einen Zähler, der sich merkt, wo eine bestimmte Datenbank schon steht. Ein bereits bestehender Grundbestand bleibt dabei unangetastet — eine neue Spalte an einer schon vorhandenen Tabelle muss deshalb ausdrücklich als eigener Nachtrag ergänzt werden, sonst fehlt sie auf älteren, gewachsenen Datenbanken weiterhin, obwohl eine frische Installation sie von Anfang an hätte. Die Nachträge sind so gebaut, dass ein zweiter oder dritter Durchlauf nichts kaputt macht: Meldet die Datenbank „gibt es schon", wird das stillschweigend übergangen. Neue Fahrzeug-, Kunden- und Auftragsdaten (siehe Kunden & Fahrzeuge und Aufträge, Angebote & Anfragen) entstehen aus genau diesem Mechanismus.
- Eine neue Spalte fehlt trotz aktuellem Programmstand → sie wurde vermutlich in den nicht wiederholbaren Grundbestand statt in die Nachtrags-Liste eingetragen; auf einer bereits laufenden Datenbank kommt sie dann nie an.
- Der Programmstart bricht beim zweiten Hochfahren ab → derselbe Fehler: ein Nachtrag landete an einer Stelle, die keine Wiederholung verträgt.
- Ein einzelner Nachtrag schlägt echt fehl (nicht nur „gibt es schon") → das System sammelt den Fehlschlag, meldet ihn einmal deutlich und startet trotzdem weiter; die fehlende Spalte fällt dann erst auf, sobald jemand eine Funktion nutzt, die sie braucht.
- lib/db/index.ts
| regel | Neue Tabellen NUR ueber die ALTERS-Sektion, NICHT ins MIGRATIONS-Array (Hausregel 3) — MIGRATIONS laeuft ohne try/catch, ein zweiter Boot bricht sonst ab; beide Arrays laufen bei JEDEM Boot komplett durch, es gibt keinen Versions-Zaehler |
|---|---|
| besonderheit | CREATE TABLE IF NOT EXISTS ruehrt eine bestehende Tabelle nicht an — neue Spalten auf gewachsenen DBs (u.a. Prod) brauchen zusaetzlich einen expliziten ALTER, sonst fehlen sie dort; tests/crm/schema-drift.test.ts haelt Drizzle-Schema und SQLite-DDL synchron; ALTERS ist idempotent (schluckt 'duplicate column'/'already exists') |
Beleg: lib/db/index.ts:46 (MIGRATIONS-Array), :1040 (ALTERS-Array), :3094-3103 (beide Arrays laufen bei jedem Boot)
Tiefer fragen
Kontext aus dem KFZ-Bozo-Handbuch
Knoten: data-schema-pflege (Betrieb · Betrieb & Dokumentation · live · geprüft Sat Sep 05 2026 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit) @ 0f0406a1)
Kurz: Wie neue Datenfelder und Tabellen sicher in die laufende Datenbank eingebaut werden, ohne bestehende Daten zu gefährden — jede Programmversion prüft beim Start automatisch, ob neue Spalten/Tabellen fehlen und legt sie nach.
Lies zuerst (Lesebereich, nicht der ganze Baum):
lib/db/index.ts
Hängt zusammen mit:
data-kunde-fahrzeug (lib/db/schema.ts) · data-auftrag (lib/db/jobs.ts) · ops-deploy (docs/hetzner-migration-runbook.md)
Offene Fragen der Seite:
keine
Hausregel 2: Vault-Daten sind für diese Session unsichtbar; Quellpfade auf Vault-Code sind keine Freigabe.
Frage: {{DEINE FRAGE}}
Antworte nur mit Belegen: nenne Datei und Zeile für jede Aussage.
Wenn die Quellen die Frage nicht beantworten, sag das und nenne, was du zusätzlich lesen müsstest.
Weicht die Seite vom Code ab, schlage den Seiten-Patch vor (wiki/seiten/betrieb-doku/data-schema-pflege.md).