---
description: Kein Migrations-Code — immer frische DB per reset-db; Live-Anpassungen nur per sqlcmd
alwaysApply: true
---

# Schema: keine Migrationen im Code

Wir gehen **immer von einer frischen Datenbank** aus. Schema-Änderungen gehören in `src/schema.js` (und ggf. `purge.js`), **nicht** als Upgrade-Pfade für bestehende DBs.

## Verboten im Repo

- `MIGRATE_*`-Scripts oder Kommentare wie „Existing DBs …“
- `ALTER TABLE … ADD <spalte>` mit `IF NOT EXISTS (SELECT … FROM sys.columns …)`
- `ALTER` nur um ein bereits ausgerolltes Schema zu patchen
- Logik „wenn Spalte/Constraint fehlt, nachrüsten“ für fremde oder alte DB-Stande

## Erlaubt

- `CREATE TABLE` mit `IF NOT EXISTS` (Neuaufbau)
- Spalten direkt in `CREATE TABLE` definieren
- **Ausnahme Zirkular-FK:** Spalte in `CREATE TABLE`, FK in separatem `INIT_*` **nach** der referenzierten Tabelle — nur für den Erst-Init, nicht als Migration
- `purge.js`: Constraint-Drops, die `reset-db`/`purge-db` zum sauberen Droppen brauchen

## Workflow

1. Schema in `src/schema.js` anpassen
2. Lokal: `npm run reset-db` (purge + init)
3. **Eigene/geteilte DB** bei Bedarf **manuell** mit `sqlcmd` anpassen — **nicht** im Code committen

## Beispiel sqlcmd (nur manuell, nicht im Repo)

```bash
sqlcmd -S "$MSSQL_SERVER" -d "$MSSQL_DATABASE" -U "$MSSQL_USER" -P "$MSSQL_PASSWORD" -Q "…"
```

Nach sqlcmd-Anpassungen: Schema-Datei trotzdem so pflegen, dass `reset-db` den Zielzustand abbildet.