Seminar NestJS – Datenbanken mit TypeORM und Prisma

Datenzugriff prägt Wartbarkeit und Laufzeit einer Backend-Anwendung stärker als die Wahl einzelner Controller-Muster. Unklare Transaktionsgrenzen, unkontrollierte Relationen und nicht reproduzierbare Migrationen führen häufig erst unter Last oder beim Deployment zu Fehlern.

Der Kurs implementiert dieselbe Fachdomäne mit TypeORM und Prisma. Unterschiede bei Modellierung, Abfragen, Typisierung, Migrationen und Testbarkeit werden praktisch sichtbar und anhand konkreter Projektanforderungen bewertet.

Inhaltsübersicht

• Lernziele
• Persistenzarchitektur und Datenmodell
• TypeORM in modularen Anwendungen
• Prisma in NestJS integrieren
• Transaktionen, Konsistenz und Nebenläufigkeit
• Abfrageperformance und Teststrategie
• Praxisprojekt: Bestell- und Lagerverwaltung
• Prüfpunkte und typische Fehler

Lernziele

• Persistenzschicht, Domänenmodell und Transportmodelle klar voneinander trennen.
• TypeORM-Module, Entities, Repositories, Query Builder und Migrationen sicher einsetzen.
• Prisma-Schema, Client, Service-Kapselung und Migrationsworkflow in NestJS integrieren.
• Transaktionen, Isolation, Nebenläufigkeit und Fehlerbehandlung fachlich korrekt gestalten.
• Abfragen anhand realer Messwerte optimieren und N+1-, Pagination- sowie Indexprobleme erkennen.
• Datenbanktests mit reproduzierbarem Schema und kontrollierten Testdaten aufbauen.

Persistenzarchitektur und Datenmodell

Fachliche Identitäten, Beziehungen, Kardinalitäten und Lebenszyklen werden vor der Framework-Konfiguration geklärt. Tabellenstrukturen und Objektmodelle dürfen gezielt voneinander abweichen.

1. Aggregate, Transaktionsgrenzen und referenzielle Integrität unterscheiden.
2. Eingabe-DTOs, Domänenobjekte, Persistenzmodelle und API-Ausgaben getrennt halten.
3. Primärschlüssel, fachliche Schlüssel, Zeitstempel und Löschstrategien festlegen.
4. Relationen nach Zugriffswegen und Änderungsverhalten modellieren.
5. Mandantenfähigkeit und Datenisolation im Schema und in Abfragen berücksichtigen.
6. Migrationen als versionierte Anwendungskomponente behandeln.

Entscheidungskriterien und Hinweise

• Datenbankconstraints bilden eine zusätzliche Schutzschicht für Invarianten.
• Soft Delete wird nur mit geklärten Eindeutigkeits-, Datenschutz- und Abfragefolgen eingesetzt.

TypeORM in modularen Anwendungen

TypeORM wird über klar abgegrenzte Infrastrukturmodule eingebunden. Repository-Ansatz, Query Builder und Transaktionssteuerung werden an realen Fachoperationen aufgebaut.

1. Datenbankkonfiguration über ein eigenes Modul und validierte Umgebungswerte bereitstellen.
2. Entities mit Schlüsseln, Constraints, Indizes und expliziten Relationen definieren.
3. Repositories in Application Services injizieren und Mapping an einer Stelle bündeln.
4. Query Builder für komplexe Filter, Aggregationen und kontrollierte Joins einsetzen.
5. Migrationen erzeugen, prüfen, ausführen und mit einem Rückwärtsplan versehen.
6. Transaktionen über QueryRunner oder einen gekapselten Transaktionsadapter steuern.
7. Optimistische und pessimistische Sperren an konkurrierenden Aktualisierungen testen.

Entscheidungskriterien und Hinweise

• Automatische Schema-Synchronisierung wird nicht für kontrollierte Produktionsänderungen verwendet.
• Eager Loading bleibt eine bewusste, lokal nachvollziehbare Entscheidung.

Prisma in NestJS integrieren

Der Prisma Client wird über einen Infrastrukturservice bereitgestellt. Schema, Migrationen und generierte Typen bilden gemeinsam den Datenzugriffsvertrag.

1. Prisma-Schema mit Modellen, Relationen, Constraints, Indizes und Namensabbildungen erstellen.
2. Client-Erzeugung und Lebenszyklus in einem wiederverwendbaren Modul kapseln.
3. Abfragen mit select und include auf den tatsächlichen Datenbedarf begrenzen.
4. Nested Writes und explizite Transaktionen hinsichtlich Fehlerverhalten vergleichen.
5. Migrationen für Entwicklung, Test und Produktion getrennt ausführen.
6. Rohabfragen nur gekapselt, parametrisiert und mit klarer Begründung einsetzen.
7. Repository-Adapter ergänzen, wenn der Domänenkern vom Client entkoppelt werden soll.

Entscheidungskriterien und Hinweise

• Generierte Typen ersetzen keine fachliche Modellierung.
• Prisma Client wird nicht unkontrolliert in allen Fachservices verteilt.

Transaktionen, Konsistenz und Nebenläufigkeit

Transaktionen werden aus fachlichen Invarianten abgeleitet. Große Transaktionen erhöhen Sperrzeiten; zu kleine Transaktionen erzeugen inkonsistente Zwischenzustände.

1. Atomare Geschäftsoperationen und zulässige Zwischenzustände dokumentieren.
2. Lost Update, Non-Repeatable Read und Phantom Read praktisch nachvollziehen.
3. Eindeutige Constraints gegen konkurrierende Duplikate verwenden.
4. Idempotente Schreiboperationen und Request-Schlüssel für Wiederholungen einführen.
5. Outbox-Muster für Nachrichten oder Integrationsereignisse einsetzen.
6. Datenbankfehler in stabile fachliche Fehler übersetzen.

Entscheidungskriterien und Hinweise

• Externe Netzwerkaufrufe gehören nicht unkontrolliert in Datenbanktransaktionen.
• Isolationsebenen werden nach tatsächlichem Konfliktrisiko ausgewählt.

Abfrageperformance und Teststrategie

SQL-Ausgaben, Ausführungspläne, Roundtrips und Datenmengen werden erfasst, bevor Caches oder komplexe Indizes ergänzt werden.

1. N+1-Abfragen durch explizite Ladepläne, Joins oder Batch-Zugriffe beseitigen.
2. Offset- und Cursor-Pagination nach Datenmenge und Sortierstabilität auswählen.
3. Indizes an Filter-, Join- und Sortiermustern ausrichten.
4. Große Ergebnisobjekte durch Projektionen und selektive Felder begrenzen.
5. Integrationstests gegen eine reale relationale Testdatenbank ausführen.
6. Schema pro Testlauf reproduzierbar migrieren und Testdaten deterministisch erzeugen.
7. Isolation durch Rollback, Schema oder getrennte Datenbanken sicherstellen.

Entscheidungskriterien und Hinweise

• Optimierungen benötigen Messwerte und einen Vorher-Nachher-Vergleich.
• Mocks ersetzen keine Prüfung von SQL, Constraints und Migrationen.

Praxisprojekt: Bestell- und Lagerverwaltung

Eine Bestell- und Lagerdomäne wird zuerst mit TypeORM und danach mit Prisma umgesetzt. Beide Varianten verwenden dasselbe API-Verhalten und dieselben fachlichen Tests.

Ein Last- und Nebenläufigkeitsszenario deckt N+1-Abfragen, fehlende Indizes und konkurrierende Reservierungen auf. Anschließend werden Abfragen und Transaktionsgrenzen optimiert.

1. Fachliches Datenmodell, Schlüssel, Relationen und Transaktionsgrenzen festlegen.
2. TypeORM-Variante mit Entities, Repositories, Migrationen und Transaktionsadapter implementieren.
3. Prisma-Variante mit Schema, Client-Modul, Migrationen und Repository-Adapter aufbauen.
4. Gemeinsame Contract-Tests für Erstellen, Ändern, Reservieren und Stornieren ausführen.
5. Konkurrierende Reservierungen simulieren und durch Constraints sowie Sperrstrategie absichern.
6. SQL-Roundtrips, Datenmengen und Ausführungspläne einer Listenabfrage messen.
7. Pagination, Projektion und Indizes optimieren und Messwerte vergleichen.
8. Entscheidungsmatrix für TypeORM oder Prisma anhand der Projektanforderungen erstellen.

Prüfpunkte und typische Fehler

• DTOs und ORM-Modelle werden nicht ungeprüft als fachliche Kernobjekte verwendet.
• Automatische Schema-Synchronisierung ersetzt keine Produktionsmigrationen.
• Eager Loading erzeugt keine unkontrollierten Datenmengen.
• Externe Aufrufe werden nicht innerhalb lang laufender Transaktionen ausgeführt.
• Optimierungen sind durch Messwerte und Ausführungspläne begründet.
• Tests verwenden ein reales Schema und reproduzierbare Migrationen.