Aufgabe 19 - Vom File zur Datenbank

Aufgabe 19 - Vom File zur Datenbank

Worum geht es?

Die dritte Repository-Implementierung: SQLite. Dank der Architektur aus Aufgabe 18 ist das ein Anbau, kein Umbau, und genau das wird nachgewiesen. Außerdem tauschen Sie erstmals strukturierte Daten mit einem fremden Projekt aus; die Lehrplan-Kompetenz “Daten mit Hilfe von strukturierten Datenformaten zwischen Anwendungen austauschen” wird damit wörtlich eingelöst (siehe Kapitel Persistenz).

Was Sie dafür brauchen

• Kapitel Persistenz; Ihr Buffet-Projekt nach Aufgabe 18.
• better-sqlite3 (oder die im Unterricht festgelegte Alternative); SQL-Grundlagen aus INSY.
• Für Teil D ein Partnerteam.

Welche Kompetenzen Sie erwerben und zeigen

• Sie binden SQLite in ein Next.js-Projekt an und implementieren ein Repository gegen das bestehende Interface.
• Sie arbeiten ausschließlich mit Prepared Statements und übersetzen zwischen Tabellenzeilen und Domänenobjekten.
• Sie entwerfen Export-/Importformate und überbrücken Formatunterschiede zwischen Anwendungen.

Pädagogische Einordnung

• Reproduktion: das Repository-Muster des Kapitels auf das eigene Schema anwenden (Teil A).
• Reorganisation und Transfer: die Persistenz in die bestehende Architektur integrieren und nachweisen (Teile B und C).
• Reflexion, Problemlösung und Urteilsbildung: einen Datenaustausch mit fremdem Format durchführen und die gefundenen Vertragslücken bewerten (Teil D).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt. Teil D ist der Expertenteil.

Teil A - Schema und Repository

1. Entwerfen Sie das Schema als schema.sql: Tabellen für Artikel, Bestellungen und Bestellpositionen, mit Fremdschlüsseln (hier zahlt das INSY-Wissen ein). Das Repository legt das Schema beim Start selbst an (CREATE TABLE IF NOT EXISTS).
2. Implementieren Sie SqliteRepository gegen Ihr BuffetRepository-Interface: ausschließlich Prepared Statements mit Platzhaltern, Abbildungsfunktionen zwischen snake_case-Zeilen und den Domänenobjekten.
3. Die Datenbankdatei kommt in die .gitignore; ins Repository gehört das Schema, nicht der Bestand.

Teil B - Der Anbau-Nachweis

1. Der Wechsel auf SQLite ist die bekannte eine Zeile in der Verdrahtung. Regel: Kein Service und keine Komponente wird angefasst. Mussten Sie doch etwas ändern, ist das ein Architekturfehler aus Aufgabe 18: dokumentieren und beheben.
2. Ihr Abnahmeskript aus Aufgabe 15 läuft unverändert gegen alle drei Repositories (Memory, Datei, SQLite) durch; protokollieren Sie die drei Läufe. Dasselbe Skript, drei Implementierungen: Das ist der Vertragstest der Datenschicht.
3. Die Nagelprobe der Persistenz: Bestellen über die Oberfläche, Dev-Server stoppen, neu starten; die Bestellung ist noch da.

Teil C - Randfälle mit echter Datenbank

1. Erzwingen Sie fachliche Eindeutigkeit per UNIQUE-Constraint (etwa Artikelname) und übersetzen Sie den Constraint-Verstoß im Repository in den fachlichen Konfliktfehler, der an der API als 409 erscheint; kein roher SQL-Fehlertext verlässt die Datenschicht.
2. Der Fall “letzter Artikel, zwei Bestellungen”: Lösen Sie zwei nahezu gleichzeitige Bestellungen auf den letzten Artikel aus (zwei parallele fetch-Aufrufe genügen). Dokumentieren Sie, was jetzt passiert, und stellen Sie sicher, dass Mengenprüfung und Abbuchung zusammen atomar laufen (Transaktion mit db.transaction(...)).

Teil D - Expertenteil: Datenaustausch zwischen Anwendungen

1. Implementieren Sie GET /api/export (kompletter Bestand als dokumentiertes JSON mit Versionsfeld) und POST /api/import (validiert das Dokument und übernimmt es; die drei Fehlerklassen jeder Datengrenze werden behandelt).
2. Tauschen Sie Exportdateien mit dem Partnerteam. Beide Teams haben dieselbe Aufgabenstellung, aber unabhängig entworfene Formate; schreiben Sie den nötigen kleinen Konverter, um deren Export in Ihre Anwendung zu importieren.
3. Protokollieren Sie jede Formatdifferenz, die der Konverter überbrücken musste (Feldnamen, Datumsformate, Zustandsbezeichnungen, Verschachtelung). Jede Differenz ist gelebte Schnittstellenlehre: Genau solche Abweichungen brechen ungeplante Integrationen.
4. Beurteilen Sie in drei Sätzen: Was hätte ein gemeinsam vereinbartes Exportformat gekostet, was hat das Fehlen gekostet, und wann lohnt sich welcher Weg?

Wissenscheck

1. Warum sind Platzhalter (?) in SQL-Statements Pflicht? Nennen Sie beide Gründe.
2. Wo wohnt die Übersetzung zwischen Tabellenzeile und Domänenobjekt, und warum genau dort?
3. Was beweist der Lauf desselben Abnahmeskripts gegen drei Repositories?
4. Wann braucht es eine Transaktion? Nennen Sie den Fall aus dieser Übung.
5. Warum ist der Datenaustausch per Export/Import ein Schnittstellenvertrag wie die API selbst?

Abgabe

Git-Repository, schema.sql, die drei protokollierten Abnahmeläufe, das Ergebnis des Gleichzeitigkeits-Tests und das Austauschprotokoll mit dem Partnerteam.