ORM

Fast jede App speichert Daten dauerhaft, also auch dann, wenn sie geschlossen wird. Dafür nutzt sie meist eine Datenbank: einen Speicher, der Informationen in Tabellen mit Zeilen und Spalten ablegt. Ein Programm denkt aber nicht in Tabellen. Es arbeitet mit sogenannten Objekten, also Datenpaketen wie „Nutzer Anna, 15 Jahre, Mail-Adresse X“. ORM ist die Vermittlungsschicht zwischen diesen beiden Welten. Sie verwandelt Objekte automatisch in Tabellenzeilen und Tabellenzeilen zurück in Objekte.

Warum Entwickler nicht direkt mit der Datenbank sprechen wollen

Ohne ORM muss man Datenbankbefehle selbst formulieren. Die Sprache dafür heißt SQL und sieht ganz anders aus als üblicher Programmcode. Ein Entwickler springt dann ständig zwischen zwei Denkweisen hin und her. Fachleute nennen diese Reibung den „Object-Relational Impedance Mismatch“, also die Unverträglichkeit zweier Datenmodelle.

Ein ORM spart deshalb vor allem Zeit. Statt zwanzig Zeilen SQL zu tippen, schreibt man einen kurzen Befehl wie „speichere diesen Nutzer“. Der Rest passiert im Hintergrund. Bei großen Projekten mit hunderten Tabellen ist dieser Unterschied enorm.

Ein zweiter Vorteil ist Sicherheit. Eine bekannte Angriffsform heißt SQL-Injection: Ein Angreifer schmuggelt über ein Eingabefeld eigene Datenbankbefehle ein. Gute ORMs behandeln Nutzereingaben grundsätzlich als reinen Text und nie als Befehl. Damit fällt eine der häufigsten Sicherheitslücken weitgehend weg.

Die Übersetzung zwischen Objekt und Tabellenzeile

Zuerst legt man fest, welche Klasse zu welcher Tabelle gehört. Eine Klasse ist die Bauanleitung für Objekte, etwa eine Vorlage „Nutzer“ mit den Feldern Name und Alter. Diese Vorlage wird der Tabelle „nutzer“ zugeordnet, Feld für Feld. Diese Zuordnung nennt man das Mapping, daher der Name.

Ruft das Programm dann eine Funktion auf, erzeugt das ORM daraus im Hintergrund den passenden SQL-Befehl. Die Datenbank liefert Zeilen zurück, und das ORM baut daraus fertige Objekte. Der Entwickler sieht von diesem Zwischenschritt nichts. Man kann es sich wie einen Dolmetscher bei einem Gespräch vorstellen: Beide Seiten reden in ihrer Muttersprache und verstehen sich trotzdem.

Ein typischer Irrtum ist, ORMs für immer schneller zu halten. Das Gegenteil kann passieren. Berüchtigt ist das N+1-Problem: Man lädt eine Liste mit 100 Beiträgen und fragt danach für jeden einzeln den Autor ab. Das sind 101 Anfragen statt einer einzigen. Erfahrene Entwickler prüfen deshalb, welche Befehle ihr ORM tatsächlich erzeugt.

Vom Webshop bis zur KI-Anwendung

ORMs stecken in fast jeder größeren Webanwendung. Bekannte Vertreter sind Hibernate für Java, Django ORM und SQLAlchemy für Python sowie Prisma für JavaScript. Wer eine Stellenanzeige für Softwareentwicklung liest, findet diese Namen regelmäßig in der Anforderungsliste.

Auch KI-Produkte nutzen ORMs, allerdings unspektakulär im Maschinenraum. Ein Chatbot-Dienst muss Konten, Abrechnungen und Gesprächsverläufe verwalten. Das Sprachmodell selbst hat damit nichts zu tun, die App drumherum sehr wohl. Interessant ist derzeit ein neuer Trend: KI-Assistenten schreiben ORM-Code inzwischen recht zuverlässig selbst.

Eine Warnung zur Abkürzung: ORM steht in Wirtschaftsnachrichten oft für „Online Reputation Management“, also die Pflege des Rufs einer Firma im Netz. Das hat mit Datenbanken nichts zu tun. Welche Bedeutung gemeint ist, verrät fast immer der Zusammenhang.