Datenmodell: Schema, tagCodes und Geheimnisse #20

2026-09-24T23:11:42Z

florian.wilde commented

2026-09-24 23:11:42 +00:00

Vollständiges Datenmodell in deutscher Benennung: 20 Tabellen, 9 Aufzählungen, eine Migration, dazu die framework-freien Helfer für tagCode und Geheimnisse.

Worum es im Kern geht

Die Service-Schicht ist der richtige Ort für Regeln mit verständlichen Meldungen — aber nicht der einzige Weg, auf dem Daten entstehen. Migrationen, psql, Skripte und ab Phase 4 die Connectoren schreiben an ihr vorbei. Was dabei stillschweigend falsch werden könnte, steht deshalb zusätzlich in der Datenbank: 12 CHECK-Bedingungen, 2 partielle Eindeutigkeitsindizes, 4 zusammengesetzte Fremdschlüssel.

Die Mandantengrenze ist einer davon: Lauf verweist mit (geraetId, kundeId) auf Geraet(id, kundeId), analog für Person und Abteilung. Ein Lauf, der ein Gerät eines fremden Kunden zieht, ist damit strukturell unmöglich statt bloß ein Fehler im Service.

Zwei Dinge kaskadieren bewusst nicht: ein Lauf nimmt seine Schrittergebnisse und Kommentare nicht mit, und ein Protokolleintrag verliert seinen Urheber nicht. Beides stünde gegen den Zweck eines Archivs. Aus demselben Grund gibt es TagCodeVergabe — ohne dieses Buch wäre ein tagCode nach dem Löschen eines Geräts wieder frei.

Was der unabhängige Review gefunden hat

Alle drei Blocker behoben:

Der im Auftrag geforderten Suchspalte Schrittergebnis.wert fehlte der Trigramm-Index.
Die im Lauf gewählte Abteilung war nur ein Wert in variablen statt ein Bezug — die Druckansicht eines archivierten Laufs wäre nicht reproduzierbar gewesen.
Für die Kundenbindung eines Benutzers (#8) gab es keine Struktur, sie hätte nur im Token stehen können — gegen die eigene Regel, Rechte pro Anfrage aus der Datenbank zu lesen.

Dazu neun kleinere Punkte, ebenfalls abgearbeitet.

Widerspruch im Auftrag, aufgelöst

Das wörtlich vorgegebene tagCode-Alphabet enthält ein L, die Klammer daneben verbietet es. Wir folgen dem Wortlaut: die Klammer benennt Verwechslungsgruppen, keine Ausschlussliste — aus {1, I, L} sind 1 und I gestrichen, wodurch L eindeutig wird, und das Präfix LZ- enthält ohnehin in jedem Code ein L. Das Akzeptanzkriterium in #6 wurde richtiggestellt, nicht der Test daran angepasst.

Prüfung

lint, typecheck, build, pruefe:doku grün. 106 Tests (vorher 11), davon 42 gegen die echten Datenbankregeln. Seed zweimal gefahren: keine Zeile geändert.

Keine Oberflächenänderung, daher kein Screenshot.

Closes #6

Vollständiges Datenmodell in deutscher Benennung: **20 Tabellen, 9 Aufzählungen**, eine Migration, dazu die framework-freien Helfer für `tagCode` und Geheimnisse. ## Worum es im Kern geht Die Service-Schicht ist der richtige Ort für Regeln mit verständlichen Meldungen — aber nicht der einzige Weg, auf dem Daten entstehen. Migrationen, `psql`, Skripte und ab Phase 4 die Connectoren schreiben an ihr vorbei. Was dabei stillschweigend falsch werden könnte, steht deshalb **zusätzlich in der Datenbank**: 12 CHECK-Bedingungen, 2 partielle Eindeutigkeitsindizes, 4 zusammengesetzte Fremdschlüssel. Die **Mandantengrenze** ist einer davon: `Lauf` verweist mit `(geraetId, kundeId)` auf `Geraet(id, kundeId)`, analog für Person und Abteilung. Ein Lauf, der ein Gerät eines fremden Kunden zieht, ist damit strukturell unmöglich statt bloß ein Fehler im Service. Zwei Dinge kaskadieren bewusst **nicht**: ein Lauf nimmt seine Schrittergebnisse und Kommentare nicht mit, und ein Protokolleintrag verliert seinen Urheber nicht. Beides stünde gegen den Zweck eines Archivs. Aus demselben Grund gibt es `TagCodeVergabe` — ohne dieses Buch wäre ein `tagCode` nach dem Löschen eines Geräts wieder frei. ## Was der unabhängige Review gefunden hat Alle drei Blocker behoben: 1. Der im Auftrag geforderten Suchspalte `Schrittergebnis.wert` fehlte der Trigramm-Index. 2. Die im Lauf gewählte Abteilung war nur ein Wert in `variablen` statt ein Bezug — die Druckansicht eines archivierten Laufs wäre nicht reproduzierbar gewesen. 3. Für die Kundenbindung eines Benutzers (#8) gab es keine Struktur, sie hätte nur im Token stehen können — gegen die eigene Regel, Rechte pro Anfrage aus der Datenbank zu lesen. Dazu neun kleinere Punkte, ebenfalls abgearbeitet. ## Widerspruch im Auftrag, aufgelöst Das wörtlich vorgegebene `tagCode`-Alphabet enthält ein **L**, die Klammer daneben verbietet es. Wir folgen dem Wortlaut: die Klammer benennt *Verwechslungsgruppen*, keine Ausschlussliste — aus `{1, I, L}` sind `1` und `I` gestrichen, wodurch `L` eindeutig wird, und das Präfix `LZ-` enthält ohnehin in jedem Code ein L. Das **Akzeptanzkriterium** in #6 wurde richtiggestellt, nicht der Test daran angepasst. ## Prüfung `lint`, `typecheck`, `build`, `pruefe:doku` grün. **106 Tests** (vorher 11), davon 42 gegen die echten Datenbankregeln. Seed zweimal gefahren: keine Zeile geändert. Keine Oberflächenänderung, daher kein Screenshot. Closes #6

florian.wilde added 1 commit 2026-09-24 23:11:42 +00:00

feat(datenmodell): Schema, tagCodes und Geheimnisse

Prüfung / pruefung (pull_request) Canceled after 0s

Details

Prüfung / pruefung (push) Canceled after 0s

Details

Prüfung / e2e (pull_request) Canceled after 0s

Details

Prüfung / e2e (push) Canceled after 0s

Details

0e79bebd33

Das vollständige Datenmodell in deutscher Benennung: 20 Tabellen, 9
Aufzählungen, eine Migration, dazu die beiden framework-freien Helfer für die
tagCodes der QR-Aufkleber und für verschlüsselte Geheimnisse.

Die tragende Entscheidung ist, wo die Regeln stehen. Die Service-Schicht ist
der richtige Ort für verständliche Meldungen, aber nicht der einzige Weg, auf
dem Daten entstehen — Migrationen, psql, Skripte und ab Phase 4 die Connectoren
schreiben an ihr vorbei. Was dabei stillschweigend falsch werden könnte, steht
deshalb zusätzlich in der Datenbank: zwölf CHECK-Bedingungen, zwei partielle
Eindeutigkeitsindizes und vier zusammengesetzte Fremdschlüssel.

Die Mandantengrenze ist einer davon. Lauf verweist mit (geraetId, kundeId) auf
Geraet(id, kundeId), analog für Person und Abteilung, und Geraet ebenso auf
seinen Besitzer. Ein Lauf, der ein Gerät eines fremden Kunden zieht, ist damit
nicht mehr bloß ein Fehler im Service, sondern strukturell unmöglich.
MATCH SIMPLE lässt einen Lauf ohne Gerät weiterhin zu.

Zwei Dinge kaskadieren bewusst nicht: ein Lauf nimmt seine Schrittergebnisse
und Kommentare nicht mit, und ein Protokolleintrag verliert seinen Urheber
nicht. Beides stünde gegen den Zweck eines Archivs. Aus demselben Grund gibt es
TagCodeVergabe: ohne dieses Buch wäre ein tagCode nach dem Löschen eines Geräts
wieder frei, und ein alter Aufkleber im Regal zeigte auf ein fremdes Objekt.

Ein unabhängiger Review-Agent hat drei Lücken gefunden, die alle behoben sind:
der im Auftrag geforderten Suchspalte Schrittergebnis.wert fehlte der
Trigramm-Index; die im Lauf gewählte Abteilung war nur ein Wert in variablen
statt ein Bezug, wodurch die Druckansicht eines archivierten Laufs nicht
reproduzierbar gewesen wäre; und für die Kundenbindung eines Benutzers (#008)
gab es keine Struktur, sie hätte also nur im Token stehen können — gegen die
eigene Regel, Rechte pro Anfrage aus der Datenbank zu lesen.

Das tagCode-Alphabet des Auftrags widerspricht sich: der wörtlich vorgegebene
Zeichensatz enthält ein L, die Klammer daneben verbietet es. Wir folgen dem
Wortlaut, weil die Klammer Verwechslungsgruppen benennt und keine
Ausschlussliste ist — aus {1, I, L} sind 1 und I gestrichen, wodurch L eindeutig
wird, und das Präfix LZ- enthält ohnehin in jedem Code ein L. Das
Akzeptanzkriterium in #006 ist richtiggestellt worden statt umgekehrt.

106 Tests, davon 42 gegen die echten Datenbankregeln.

Closes #6

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

florian.wilde merged commit 7a0f875f55 into main

2026-09-24 23:11:59 +00:00

florian.wilde deleted branch feat/6-datenmodell

2026-09-24 23:11:59 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: florian.wilde/Laufzettel#20