Datenzugriff und Persistenz

Was ist objektrelationales Mapping (ORM)?

ORM, Object-Relational Mapping

Objektrelationales Mapping ist eine Technik, bei der eine Bibliothek Klassen deiner Anwendung auf Tabellen einer relationalen Datenbank abbildet und die passenden SQL-Anweisungen erzeugt, statt dass du sie von Hand schreibst.

Ein Aufruf, der im Code nach einer harmlosen Schleife aussieht, schickt hinterher hunderte Abfragen an die Datenbank. Genau dort wird ein ORM zum Thema.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Bekannte Vertreter: Hibernate, Entity Framework, Doctrine, Prisma
Bildet ab: Klassen auf Tabellen, Beziehungen auf Schlüssel
Klassiker: N+1-Abfragen durch nachgeladene Beziehungen
Grenze: Auswertungen und Massenänderungen

Entity, Persistenzkontext, Beziehungen

In Java ist die Schnittstelle dafür JPA, umgesetzt meist durch Hibernate. Eine Klasse wird als Entity markiert, ihre Felder werden Spalten, und eine Kennung dient als Primärschlüssel. Beziehungen bekommen eigene Annotationen: OneToMany für die Positionen einer Bestellung, ManyToOne für den Weg zurück.

Die Objekte leben in einem Persistenzkontext. Solange sie dort verwaltet sind, verfolgt das ORM Änderungen und schreibt sie beim Commit zurück, ohne dass ein Update im Code steht. Das ist bequem und die Quelle vieler Überraschungen, wenn jemand ein Feld in einer Methode ändert, die eigentlich nur lesen wollte.

Lazy Loading und das N-plus-1-Problem

Beziehungen auf viele Objekte lädt JPA erst, wenn du sie anfasst, Beziehungen auf ein einzelnes Objekt dagegen sofort: OneToMany und ManyToMany stehen standardmäßig auf lazy, ManyToOne und OneToOne auf eager. Läufst du über hundert Bestellungen, zu denen jeweils ein Kunde gehört, setzt das ORM leicht hundert zusätzliche Abfragen ab, plus die eine für die Liste. Genau das ist das N-plus-1-Problem, und im Code ist es unsichtbar, weil dort nur ein Feldzugriff steht, bei eager geladenen Beziehungen nicht einmal das.

Die Lösung ist, die Beziehung schon beim Laden mitzunehmen, in JPQL über join fetch oder über einen Entity Graph. Wichtig ist die Diagnose: Schalte im Test die Ausgabe der erzeugten Anweisungen ein oder zähle sie mit. Wer die Abfragen nie sieht, merkt den Unterschied erst, wenn die Datenmenge in Produktion wächst.

Der Gegenfehler ist, alles sofort mitzuladen. Dann zieht ein einziger Zugriff halbe Objektgraphen mit, und die Abfrage wird durch die Joins breit und langsam. Die brauchbare Regel: alle Beziehungen ausdrücklich auf lazy stellen, gerade die, die von Haus aus eager sind, und pro Anwendungsfall entscheiden, was mitkommt.

Wo ein ORM nicht die richtige Antwort ist

Für Massenoperationen ist ein ORM das falsche Werkzeug. Eine Million Zeilen als Objekte zu laden, zu ändern und zurückzuschreiben, kostet ein Vielfaches einer einzigen Update-Anweisung. Für Auswertungen mit Gruppierungen und Fensterfunktionen gilt dasselbe, dort schreibst du besser direktes SQL, was JPA über native Queries erlaubt.

Ein ORM ersetzt außerdem keine SQL-Kenntnisse. Es verschiebt nur, wann du sie brauchst: nicht beim Schreiben, sondern beim Erklären, warum eine Seite drei Sekunden lädt. Wer den Ausführungsplan lesen kann, findet das in Minuten.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

Objektrelationales Mapping und was oft damit gleichgesetzt wird

Objektrelationales Mapping gegen JDBC

JDBC ist der direkte Zugang zur Datenbank mit SQL im Code. Ein ORM setzt darauf auf, du kannst aber jederzeit auf die Ebene darunter zurückfallen, wenn eine Abfrage genau kontrolliert werden soll.

Objektrelationales Mapping gegen Query Builder

Werkzeuge wie jOOQ bauen typsicher SQL zusammen, ohne Objekte zu verwalten. Du behältst die Kontrolle über jede Anweisung und verzichtest dafür auf Änderungsverfolgung und Caching.

Objektrelationales Mapping gegen Repository

Das Repository ist ein Entwurfsmuster für den Zugriff auf eine Sammlung von Objekten. Spring Data setzt es über JPA um, ist aber selbst kein ORM, sondern eine Schicht darüber.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Das erzeugte SQL bleibt deine Verantwortung

Der Unterschied zwischen einer und zweihundert Abfragen steht nicht im Quelltext. Eine Schleife über Bestellungen, die je Bestellung den Kunden anfasst, lädt diesen Kunden bei verzögertem Laden einzeln nach. Sichtbar wird das erst im Protokoll der abgesetzten Anweisungen, und deshalb gehört dieses Protokoll in der Entwicklungsumgebung eingeschaltet.

Für Auswertungen über große Mengen ist der Umweg über Objekte der falsche Weg. Eine Summe über eine Million Zeilen gehört als Abfrage in die Datenbank und nicht in eine Schleife im Anwendungsserver. Fast jedes ORM lässt daneben eigenes SQL zu, und dieser Ausweg ist kein Versagen, sondern vorgesehen.

Der dritte Punkt ist das Schema. Wer die Tabellen aus den Klassen erzeugen lässt, bekommt eine Struktur, die zur Anwendung passt und selten zu dem, was die Auswertungsseite braucht. Sobald ein zweites System auf dieselbe Datenbank schaut, führt an versionierten Migrationen und einem bewusst entworfenen Schema nichts vorbei.

Objektrelationales Mapping lernen

Wie du erzeugte Abfragen sichtbar machst und ein N-plus-1-Problem abstellst, zeigen die Trainings zu JPA und Datenbankzugriff mit Java an einem echten Datenmodell.

Die Ebene darunter, also Modell, Index und Ausführungsplan, behandeln die Kurse zu Datenbanken und SQL .

Kurse, die Objektrelationales Mapping behandeln

Häufige Fragen

Soll ich das Datenbankschema aus den Entities erzeugen lassen?

In der Entwicklung ist das bequem, in Produktion nicht. Dort gehört das Schema unter Versionskontrolle, mit Werkzeugen wie Flyway oder Liquibase, damit jede Änderung nachvollziehbar und rückgängig zu machen ist.

Warum sehe ich Änderungen, die ich nie gespeichert habe?

Weil verwaltete Entities beim Commit automatisch zurückgeschrieben werden. Wenn du nur lesen willst, arbeite in einer als readOnly markierten Transaktion oder mit einer Projektion, die keine vollständige Entity liefert.

Lohnt sich ein ORM für ein kleines Projekt?

Wenn dein Datenmodell mehr als eine Handvoll Tabellen hat und du dieselben Objekte an vielen Stellen brauchst, ja. Bei wenigen, festen Abfragen bist du mit direktem SQL oder einem Query Builder schneller unterwegs.

Persönlich für dich da