Jeffrey Ullmans Datenbanktheorie hinter schnellen, skalierbaren Abfragen

Warum Ullman für moderne Datenarbeit relevant ist

Die meisten, die SQL schreiben, Dashboards bauen oder eine langsame Abfrage tunen, profitieren von Jeffrey Ullmans Arbeit — selbst wenn sie seinen Namen nie gehört haben. Ullman ist Informatiker und Lehrender; seine Forschung und Lehrbücher haben definiert, wie Datenbanken Daten beschreiben, über Abfragen nachdenken und sie effizient ausführen.

Der leise Einfluss hinter alltäglichen Werkzeugen

Wenn eine Datenbank-Engine dein SQL in etwas übersetzt, das schnell läuft, stützt sie sich auf Ideen, die präzise und anpassbar sein müssen. Ullman half dabei, die Bedeutung von Abfragen zu formalisieren (damit das System sie sicher umschreiben kann) und die Datenbank- mit der Compiler-Denke zu verbinden (damit eine Abfrage geparst, optimiert und in ausführbare Schritte übersetzt wird).

Dieser Einfluss ist unscheinbar, weil er nicht als Button in deinem BI-Tool erscheint. Er zeigt sich als:

• Abfragen, die nach dem Hinzufügen eines Index oder dem Umformulieren eines JOIN schnell laufen
• Optimierer, die mit wachsendem Datenvolumen andere Pläne wählen
• Systeme, die skalieren können, ohne dass sich das Abfrageergebnis ändert

Was du in diesem Artikel lernst (ohne Mathe-Überladung)

Dieser Beitrag nutzt Ullmans Kernideen als Tour durch die Datenbank-Interna, die in der Praxis am meisten zählen: wie relationale Algebra SQL zugrunde liegt, wie Abfrageumschreibungen die Bedeutung bewahren, warum kostenbasierte Optimierer bestimmte Entscheidungen treffen und wie Join-Algorithmen oft entscheiden, ob ein Job Sekunden oder Stunden braucht.

Wir ziehen auch einige compilerähnliche Konzepte heran — Parsen, Umschreiben und Planen — weil Datenbank-Engines mehr wie ausgefeilte Compiler arbeiten, als viele vermuten.

Ein kurzes Versprechen: Wir halten die Darstellung akkurat, aber vermeiden mathe-lastige Beweise. Ziel sind mentale Modelle, die du beim nächsten Performance-, Skalierungs- oder unerwarteten Abfrageverhalten im Job anwenden kannst.

Datenbank-Grundlagen, die Ullman mitgeprägt hat

Wenn du je eine SQL-Abfrage geschrieben und erwartet hast, sie „meint nur eine Sache“, verlässt du dich auf Ideen, die Jeffrey Ullman populär gemacht und formalisiert hat: ein klares Datenmodell plus präzise Wege, was eine Abfrage fordert.

Das relationale Modell in klaren Worten

Im Kern behandelt das relationale Modell Daten als Tabellen (Relationen). Jede Tabelle hat Zeilen (Tupel) und Spalten (Attribute). Das klingt heute offensichtlich, wichtig ist aber die Disziplin, die daraus entsteht:

• Schlüssel identifizieren Zeilen. Ein Primärschlüssel ist das „Namensschild“ für jeden Datensatz.
• Beziehungen verbinden Tabellen über Fremdschlüssel, so dass Fakten an einem Ort gehalten und an anderer Stelle referenziert werden können.

Diese Einordnung erlaubt es, Korrektheit und Performance vorhersehbar zu machen. Wenn du weißt, was eine Tabelle repräsentiert und wie Zeilen identifiziert werden, kannst du vorhersagen, was Joins tun sollten, was Duplikate bedeuten und warum bestimmte Filter Ergebnisse verändern.

Relationale Algebra: ein Taschenrechner für Abfragen

Ullmans Lehre nutzt oft die relationale Algebra als eine Art Abfrage-Rechner: eine kleine Menge von Operationen (Selektion, Projektion, Join, Union, Differenz), die du kombinieren kannst, um auszudrücken, was du willst.

Warum das für die praktische Arbeit mit SQL wichtig ist: Datenbanken übersetzen SQL in eine algebraische Form und schreiben sie dann in eine andere äquivalente Form um. Zwei Abfragen, die unterschiedlich aussehen, können algebraisch gleich sein — so können Optimierer Joins neu anordnen, Filter nach unten ziehen oder redundante Arbeit entfernen, ohne die Bedeutung zu verändern.

Algebra vs. Kalkül (oberflächlich)

• Relationale Algebra ist mehr „wie“: eine Abfolge von Operationen zur Berechnung des Ergebnisses.
• Relationaler Kalkül ist mehr „was“: eine Beschreibung des gewünschten Ergebnisses.

SQL ist überwiegend „was“, Engines optimieren aber häufig mit algebraischen „wie“-Techniken.

Fundament schlägt Dialekt auswendig lernen

SQL-Dialekte unterscheiden sich (Postgres vs. Snowflake vs. MySQL), aber die Grundlagen nicht. Schlüssel, Beziehungen und algebraische Äquivalenzen helfen dir zu erkennen, wann eine Abfrage logisch falsch ist, wann sie nur langsam ist und welche Änderungen die Bedeutung über Plattformen hinweg erhalten.

Relationale Algebra: die verborgene Sprache unter SQL

Die relationale Algebra ist die „Mathematik unter“ SQL: eine kleine Menge von Operatoren, die das gewünschte Ergebnis beschreiben. Ullmans Arbeit hat diese Operatorensicht klar und lehrbar gemacht — und sie ist noch immer das mentale Modell, das die meisten Optimierer verwenden.

Die Kernoperatoren (und was sie bedeuten)

Eine Datenbankabfrage lässt sich als Pipeline weniger Bausteine ausdrücken:

• Selektion (σ): Zeilen filtern (entspricht WHERE in SQL)
• Projektion (π): bestimmte Spalten behalten (entspricht SELECT col1, col2)
• Join (⋈): Tabellen anhand einer Bedingung kombinieren (JOIN ... ON ...)
• Union (∪): Ergebnisse mit gleicher Form übereinanderlegen (UNION)
• Differenz (−): Zeilen in A, aber nicht in B (ähnlich EXCEPT)

Weil die Menge klein ist, wird es leichter, über Korrektheit zu argumentieren: Sind zwei algebraische Ausdrücke äquivalent, liefern sie für jeden gültigen Datenbankzustand dieselbe Tabelle.

Wie SQL konzeptionell zu Algebra abbildet

Nehmen wir eine vertraute Abfrage:

SELECT c.name
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE o.total > 100;

Konzeptionell ist das:

1. Beginne mit einem Join von customers und orders: customers ⋈ orders

2. Selektiere nur Bestellungen über 100: σ(o.total > 100)(...)

3. Projiziere die gewünschte Spalte: π(c.name)(...)

Das ist nicht die genaue interne Notation jeder Engine, aber die richtige Idee: SQL wird zu einem Operatorbaum.

Äquivalenz: die Tür zur Optimierung

Viele verschiedene Bäume können dasselbe bedeuten. Filter lassen sich oft früher anwenden (σ vor einem großen Join) und Projektionen können ungenutzte Spalten frühzeitig entfernen (π früher anwenden).

Diese Äquivalenzregeln erlauben es einer Datenbank, deine Abfrage in einen günstigeren Plan umzuschreiben, ohne das Ergebnis zu ändern. Wenn man Abfragen als Algebra sieht, wird „Optimierung“ weniger magisch und mehr regelgesteuerte Umformung.

Von SQL zu Abfrageplänen: Umschreibungen, die Bedeutung bewahren

Wenn du SQL schreibst, führt die Datenbank es nicht „wie geschrieben“ aus. Sie übersetzt deine Anweisung in einen Abfrageplan: eine strukturierte Darstellung der auszuführenden Arbeit.

Ein gutes mentales Modell ist ein Baum von Operatoren. Blätter lesen Tabellen oder Indizes; innere Knoten transformieren und kombinieren Zeilen. Gängige Operatoren sind Scan, Filter/Selektion, Projektion, Join, Gruppierung/Aggregation und Sortierung.

Logischer Plan vs. physischer Plan (was vs. wie)

Datenbanken trennen Planung typischerweise in zwei Ebenen:

• Logischer Plan: was berechnet werden soll, ausgedrückt mit abstrakten Operatoren (Filter, Join, Aggregat) und ihren Beziehungen.
• Physischer Plan: wie das auf realem Speicher und Hardware ausgeführt wird (Index-Scan vs. Full-Scan, Hash-Join vs. Nested-Loop-Join, parallel vs. single-threaded).

Ullmans Einfluss zeigt sich in der Betonung auf bedeutungserhaltenden Transformationen: den logischen Plan in vielen Varianten umordnen, ohne die Antwort zu ändern, und dann eine effiziente physische Strategie wählen.

Regelbasierte Umschreibungen, die Arbeit reduzieren

Bevor die finale Ausführungsstrategie gewählt wird, wenden Optimierer algebraische „Aufräum“-Regeln an. Diese Umschreibungen ändern nicht das Ergebnis; sie reduzieren unnötige Arbeit.

Gängige Beispiele:

• Selection Pushdown: Filter so früh wie möglich anwenden, damit weniger Zeilen in spätere Schritte fließen.
• Projection Pruning: Nur benötigte Spalten behalten, um I/O und Speicher zu reduzieren.
• Join-Reihenfolge ändern: Zuerst kleinere/intermediate Ergebnisse joinen, wenn es sinnvoll ist, statt der Reihenfolge im SQL zu folgen.

Ein einfaches Umschreibungsbeispiel

Angenommen, du willst Bestellungen von Nutzern in einem Land:

SELECT o.order_id, o.total
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE u.country = 'CA';

Eine naive Umsetzung könnte alle Nutzer mit allen Bestellungen joinen und anschließend auf Kanada filtern. Eine bedeutungserhaltende Umschreibung zieht den Filter nach unten, sodass der Join weniger Zeilen berührt:

• Nutzer auf country = 'CA' filtern
• Diese Nutzer dann mit Bestellungen joinen
• Dann nur order_id und total projizieren

In Planungsterminologie versucht der Optimierer Join(Users, Orders) → Filter(country='CA') → Project(order_id,total) in etwas wie Filter(country='CA') on Users → Join(with Orders) → Project(order_id,total) zu verwandeln — gleiche Antwort, weniger Arbeit.

Diese Umschreibungen sind leicht zu übersehen, weil du sie nie tippst — und doch sind sie ein Hauptgrund, warum dasselbe SQL in einer Datenbank schnell und in einer anderen langsam laufen kann.

Kostenbasierte Optimierung ohne Fachchinesisch

Wenn du eine SQL-Abfrage ausführst, betrachtet die Datenbank mehrere gültige Wege, dasselbe Ergebnis zu erreichen, und wählt dann den, der am günstigsten eingeschätzt wird. Dieser Entscheidungsprozess heißt kostenbasierte Optimierung — und ist ein sehr praktischer Ort, an dem Ullman-artige Theorie im Alltag sichtbar wird.

Was ein „Kostenmodell" wirklich ist

Ein Kostenmodell ist ein Bewertungssystem, das der Optimierer benutzt, um Alternativpläne zu vergleichen. Die meisten Engines schätzen Kosten anhand weniger Kernressourcen:

• Verarbeitete Zeilen (Arbeit skaliert meist mit der Datenmenge, die durch einen Schritt fließt)
• I/O (Lesen von Seiten von Festplatte/SSD, inklusive Cache-Effekte)
• CPU (Filtern, Hashen, Sortieren, Aggregieren)
• Speicher (passt eine Operation in RAM oder wird ausgelagert)

Das Modell muss nicht perfekt sein; es muss oft genug in die richtige Richtung zeigen, um gute Pläne zu wählen.

Kardinalitätsabschätzung, in einfachen Worten

Bevor er Pläne bewertet, fragt der Optimierer an jedem Schritt: Wie viele Zeilen wird das hier produzieren? Das ist die Kardinalitätsabschätzung.

Wenn du WHERE country = 'CA' filterst, schätzt die Engine, welcher Anteil der Tabelle passt. Beim Join von Kunden und Bestellungen schätzt sie, wie viele Paare aufgrund des Join-Keys übereinstimmen. Diese Zeilenzahlen bestimmen, ob ein Index-Scan besser ist als ein Full-Scan, ein Hash-Join besser als ein Nested-Loop, oder ob ein Sortieren klein oder riesig wird.

Warum Statistiken wichtig sind (und was schiefgeht ohne sie)

Die Schätzungen des Optimierers basieren auf Statistiken: Counts, Wertverteilungen, Nullraten und manchmal Korrelationen zwischen Spalten.

Sind Statistiken veraltet oder fehlen sie, kann die Engine Zeilenzahlen um Größenordnungen falsch schätzen. Ein auf dem Papier günstiger Plan kann in der Realität teuer werden — typische Symptome sind plötzliche Verlangsamungen nach Datenwachstum, „zufällige" Planwechsel oder Joins, die unerwartet auf Festplatte auslagern.

Der unvermeidliche Kompromiss: Genauigkeit vs. Planungszeit

Bessere Schätzungen erfordern oft mehr Aufwand: detailliertere Stats, Sampling oder das Durchprobieren mehrerer Kandidatenpläne. Planung selbst kostet Zeit, insbesondere bei komplexen Abfragen.

Deshalb balancieren Optimierer zwei Ziele:

• Schnell genug planen für interaktive Workloads
• Klug genug planen, um katastrophale Entscheidungen zu vermeiden

Wenn du EXPLAIN liest, hilft dir dieses Verständnis: Der Optimierer versucht nicht, „clever“ zu sein — er versucht, vorhersehbar richtig zu sein mit begrenzten Informationen.

Join-Algorithmen und das Herzstück der Abfrage-Performance

Ullmans Arbeit half eine einfache, aber mächtige Idee zu verbreiten: SQL wird nicht so sehr „ausgeführt“ wie übersetzt. Nirgends ist das offensichtlicher als bei Joins. Zwei Abfragen, die dieselben Zeilen liefern, können sich in der Laufzeit massiv unterscheiden, je nachdem, welchen Join-Algorithmus die Engine wählt und in welcher Reihenfolge sie Tabellen joined.

Nested Loop, Hash Join, Merge Join — wann welcher passt

Nested Loop Join ist konzeptionell simpel: für jede Zeile links, finde passende Zeilen rechts. Schnell, wenn die linke Seite klein ist und die rechte Seite einen passenden Index hat.

Hash Join baut eine Hashtabelle aus einem Input (meist dem kleineren) und fragt sie mit dem anderen ab. Stark für große, unsortierte Inputs mit Gleichheitsbedingungen (z. B. A.id = B.id), benötigt aber Speicher; Spill auf die Festplatte kann den Vorteil aufheben.

Merge Join geht zwei Inputs in sortierter Reihenfolge durch. Gut, wenn beide Seiten bereits nach dem Join-Key geordnet sind (z. B. durch Indizes), oder wenn das Sortieren günstig ist.

Warum die Join-Reihenfolge alles bestimmen kann

Bei drei oder mehr Tabellen explodiert die Anzahl möglicher Join-Reihenfolgen. Wenn man zuerst zwei große Tabellen joined, kann dies ein riesiges Zwischenresultat erzeugen, das alles verlangsamt. Besser ist oft, mit dem selektivsten Filter zu starten (wenige Zeilen) und nach außen zu joinen, um Zwischenresultate klein zu halten.

Indizes verändern die Auswahl guter Pläne

Indizes beschleunigen nicht nur Lookups — sie machen bestimmte Join-Strategien überhaupt erst sinnvoll. Ein Index auf dem Join-Key kann einen teuren Nested Loop in ein schnelles „pro Zeile seek“ verwandeln. Fehlen Indizes oder sind sie unbrauchbar, bevorzugt die Engine vielleicht Hash-Joins oder große Sorts für Merge-Joins.

Praktische Checkliste: Symptome eines schlechten Join-Plans

• Laufzeit wächst drastisch bei leichtem Datenwachstum (Join-Reihenfolge vergrößert Zwischenresultate).
• Im Plan tauchen große Unterschiede zwischen geschätzten und tatsächlichen Zeilen auf (schlechte Kardinalitätsschätzungen führen zu falschen Join-Entscheidungen).
• Du siehst große Sorts oder Hash-Spills auf die Festplatte (Specknappheit oder fehlende unterstützende Indizes).
• Eine kleine gefilterte Tabelle wird spät gejoint statt früh (Filter werden nicht früh genug angewendet).
• Das Join-Prädikat ist keine einfache Gleichheit auf kompatiblen Typen (verhindert effiziente Hash-/Merge-Verfahren).

Compiler-Ideen innerhalb von Datenbank-Engines

Datenbanken führen SQL nicht einfach aus — sie kompilieren es. Ullmans Einfluss reicht über Datenbank-Theorie hinaus zur Compiler-Denke, und diese Verbindung erklärt, warum Abfrage-Engines wie Toolchains für Programmiersprachen arbeiten: sie übersetzen, schreiben um und optimieren, bevor sie etwas tun.

Parsen und Syntaxbäume: wie SQL gelesen wird

Wenn du eine Abfrage sendest, ist der erste Schritt sehr compiler-ähnlich. Die Engine tokenisiert Keywords und Bezeichner, prüft Grammatik und baut einen Parse-Tree (meist vereinfacht zum Abstract Syntax Tree) auf. Hier werden grundlegende Fehler abgefangen: fehlende Kommata, mehrdeutige Spaltennamen, ungültige GROUP-BY-Regeln.

Ein hilfreiches Modell: SQL ist eine Programmiersprache, deren „Programm“ Datenbeziehungen statt Schleifen beschreibt.

Vom Parse-Tree zu logischen Operatoren

Compiler wandeln Syntax in eine Intermediate Representation (IR) um. Datenbanken tun Ähnliches: Sie übersetzen SQL in logische Operatoren wie:

• Selektion (Filtern von Zeilen)
• Projektion (Auswahl von Spalten)
• Join (Kombinieren von Tabellen)
• Aggregation (GROUP BY)

Diese logische Form ist näher an relationaler Algebra als an SQL-Text und erleichtert das Denken über Bedeutung und Äquivalenz.

Warum Optimierer Compiler-Optimierungen ähneln

Compiler-Optimierungen erhalten das Programmverhalten bei gleichzeitig geringeren Ausführungskosten. Datenbank-Optimierer machen dasselbe, mit Regelwerken wie:

• Filter früher anwenden (Arbeit früher reduzieren)
• Joins neu anordnen (gleiches Ergebnis, andere Kosten)
• Redundante Berechnungen entfernen

Das ist die Datenbank-Variante von „dead code elimination“: nicht identische Techniken, aber dieselbe Philosophie — Semantik bewahren, Kosten reduzieren.

Debugging: Pläne wie kompilierten Code lesen

Wenn deine Abfrage langsam ist, starr nicht nur auf das SQL. Schau dir den Abfrageplan an, wie du Compiler-Output anschauen würdest. Ein Plan sagt dir, was die Engine tatsächlich gewählt hat: Join-Reihenfolge, Index-Nutzung und wo Zeit verbracht wird.

Praktische Folgerung: Lerne EXPLAIN als Leistungssatz zu lesen — das macht Tuning evidenzbasiert statt ratenbasiert. Mehr dazu: /blog/practical-query-optimization-habits.

Schema-Design-Theorie, die echte Performance beeinflusst

Gute Abfrage-Performance beginnt oft, bevor du SQL schreibst. Ullmans Schema-Design-Theorie (insbesondere Normalisierung) zielt darauf ab, Daten so zu strukturieren, dass die DB Konsistenz und Vorhersagbarkeit behält, während sie wächst.

Ziele der Normalisierung (warum sie existiert)

Normalisierung will:

• Anomalien reduzieren (z. B. eine Kundenadresse an fünf Stellen aktualisieren und eine zu vergessen)
• Konsistenz verbessern, indem jede Tatsache ein „Zuhause“ hat
• Constraints ausdrückbar machen (Schlüssel, Fremdschlüssel), damit die Engine Regeln durchsetzen kann statt die Anwendung

Diese Korrektheitsgewinne führen später zu Performancevorteilen: weniger duplizierte Felder, kleinere Indizes und weniger teure Updates.

Normalformen in einfachen Worten

Du musst keine Beweise kennen, um die Ideen zu nutzen:

• 1NF: Werte in atomaren Spalten speichern (keine komma-getrennten Listen). Das erleichtert Filtern und Indexierung.
• 2NF: In Tabellen mit zusammengesetztem Schlüssel sollten alle Nicht-Schlüssel-Spalten vom gesamten Schlüssel abhängen, nicht nur von einem Teil.
• 3NF: Nicht-Schlüssel-Spalten sollten nur vom Schlüssel abhängen, nicht von anderen Nicht-Schlüssel-Spalten.
• BCNF: Strenger als 3NF: jede Determinante ist ein Kandidatenschlüssel — nützlich bei „fast eindeutigen" Spalten, die subtile Duplikate erzeugen.

Wann Denormalisierung sinnvoll ist

Denormalisierung kann sinnvoll sein, wenn:

• Du analytics-lastige Tabellen baust (breite Faktentabellen, Reporting)
• Joins der Flaschenhals sind und du kontrollierte Redundanz akzeptieren kannst
• Du für Lesegeschwindigkeit optimierst mit klaren Aktualisierungsregeln (z. B. nächtliche Rebuilds)

Wichtig ist, bewusst zu denormalisieren und einen Prozess zu haben, die Duplikate synchron zu halten.

Wie Schema-Entscheidungen Optimierer und Skalierung beeinflussen

Das Schema beeinflusst, was der Optimierer tun kann. Klare Schlüssel und Fremdschlüssel ermöglichen bessere Join-Strategien, sicherere Umschreibungen und genauere Zeilenschätzungen. Übermäßige Duplikation kann Indizes aufblähen und Schreibvorgänge verlangsamen; mehrwertige Spalten verhindern effiziente Prädikate. Mit wachsendem Datenvolumen spielen diese frühen Modellierungsentscheidungen oft eine größere Rolle als Mikro-Optimierungen einzelner Abfragen.

Wie Theorie sich zeigt, wenn Systeme skalieren

Wenn ein System skaliert, geht es selten nur darum, größere Maschinen hinzuzufügen. Häufiger ist die Herausforderung, dieselbe Abfragebedeutung beizubehalten, während die Engine eine sehr andere physische Strategie wählt, um Laufzeiten vorhersehbar zu halten. Ullmans Fokus auf formale Äquivalenzen ist genau das, was diese Strategieänderungen erlaubt, ohne Ergebnisse zu verändern.

Skalierung ist oft physisches Layout + Planwahl

Bei kleinen Datenmengen funktionieren viele Pläne. Bei Skala kann der Unterschied zwischen Tabellenscan, Indexnutzung oder vorcomputiertem Ergebnis Sekunden vs. Stunden bedeuten. Theorie hilft, weil der Optimierer eine sichere Menge von Umschreiberegeln braucht (z. B. Filter früher ziehen, Joins umordnen), die das Ergebnis nicht verändern — selbst wenn sie die ausgeführte Arbeit radikal verändern.

Partitionierung ändert die tatsächlich ausgeführte Abfrage, obwohl SQL gleich aussieht

Partitionierung (nach Datum, Kunde, Region usw.) teilt eine logische Tabelle in viele physische Teile. Das beeinflusst die Planung:

• Welche Partitionen übersprungen werden können (Partition Pruning)
• Ob Joins innerhalb von Partitionen stattfinden oder Daten über Knoten hinweg verschoben werden müssen
• Ob Gruppierungen lokal gemacht werden können, bevor Ergebnisse kombiniert werden

Der SQL-Text bleibt gleich, aber der beste Plan hängt davon ab, wo die Zeilen liegen.

Materialisierte Views: Vorberechnung als algebraische Abkürzung

Materialisierte Views sind gespeicherte Zwischenausdrücke. Kann die Engine beweisen, dass deine Abfrage mit einem gespeicherten Ergebnis übereinstimmt (oder auf dieses umgeschrieben werden kann), kann sie teure Arbeit wie wiederholte Joins und Aggregationen durch einen schnellen Lookup ersetzen. Das ist relationale Algebra in der Praxis: Äquivalenz erkennen und wiederverwenden.

Caching hilft, kann aber die falsche Arbeitsform nicht reparieren

Caching beschleunigt wiederholte Lesezugriffe, kann aber eine Abfrage nicht retten, die zu viel Daten scannen, riesige Zwischen-Joins erzeugen oder umfangreiche Shuffles durchführen muss. Bei Skalierungsproblemen ist die Lösung oft: reduziere die Datenmenge (Layout/Partitionierung), reduziere wiederholte Berechnung (materialisierte Views) oder ändere den Plan — nicht nur „mehr Cache".

Praktische Optimierungsgewohnheiten, inspiriert von Ullman

Ullmans Einfluss zeigt sich in einer einfachen Mentalität: Behandle eine langsame Abfrage als Absichtserklärung, die die Datenbank frei umschreiben darf, und verifiziere dann, was sie tatsächlich getan hat. Du musst kein Theoretiker sein, um davon zu profitieren — du brauchst nur eine wiederholbare Routine.

1) Lies einen EXPLAIN-Plan: worauf zuerst achten

Beginne mit den Teilen, die normalerweise die Laufzeit dominieren:

• Zugriffsart: scannt die Engine eine ganze Tabelle, obwohl du einen Index-Lookup erwartest?
• Schätzungen vs. Tatsachen (falls deine DB beide zeigt): große Lücken erklären oft merkwürdige Langsamkeit.
• Join-Reihenfolge: Welche Tabelle treibt den Join, und beginnt sie mit dem selektivsten Filter?
• Teure Operatoren: Sorts, Hash-Builds, große Nested Loops — hier steckt oft die Arbeit.

Wenn du nur eins tust: finde den ersten Operator, bei dem die Zeilenanzahl explodiert. Das ist meist die Ursache.

2) Häufige Anti-Patterns, die Optimierer ausbremsen

Diese sind leicht zu schreiben und erstaunlich teuer:

• Funktionen auf indizierten Spalten: WHERE LOWER(email) = ... kann Indexnutzung verhindern (verwende eine normalisierte Spalte oder einen funktionalen Index, falls unterstützt).
• Fehlende Prädikate: Ein vergessenes Datumsintervall oder Tenant-Filter macht eine gezielte Abfrage zum großen Scan.
• Unbeabsichtigte Cross-Joins: Eine fehlende Join-Bedingung kann Zeilen vervielfachen und enorme Zwischenresultate erzeugen.

3) Formuliere eine Hypothese mit algebraischem Denken

Relationale Algebra führt zu zwei praktischen Schritten:

• Filter früher anwenden: WHERE-Bedingungen vor Joins ziehen, wenn möglich, um Inputs zu verkleinern.
• Spalten früh reduzieren: Nur benötigte Spalten wählen (besonders vor Joins), um Speicher und I/O zu sparen.

Eine gute Hypothese könnte lauten: „Dieser Join ist teuer, weil zu viele Zeilen gejoint werden; wenn wir orders vorab auf die letzten 30 Tage filtern, sinkt der Join-Input.“

4) Index, Umschreiben oder Schema-Änderung?

Ein einfaches Entscheidungsprinzip:

• Index hinzufügen, wenn die Abfrage korrekt, selektiv und häufig ausgeführt wird.
• Abfrage umschreiben, wenn EXPLAIN vermeidbare Arbeit zeigt (unnötige Joins, spätes Filtern, nicht-sargable Prädikate).
• Schema ändern, wenn das Workload-Muster stabil ist und du ständig denselben Flaschenhals bekämpfst (z. B. vorcomputierte Aggregationen, denormalisierte Lookup-Felder oder Partitionierung nach Zeit/Tenant).

Ziel ist nicht „cleveres SQL“, sondern vorhersehbar kleinere Zwischenresultate — genau die Art von äquivalenzerhaltenden Verbesserungen, die Ullmans Ideen erleichtern.

Diese Ideen anwenden, wenn du echte Produkte baust

Die Konzepte sind nicht nur für DBAs. Wenn du eine Anwendung auslieferst, triffst du Datenbank- und Abfrageplan-Entscheidungen, ob du es merkst oder nicht: Schema-Form, Schlüsselauswahl, Abfragemuster und Data-Access-Layer beeinflussen, was der Optimierer kann.

Wenn du einen vibe-coding-Workflow nutzt (z. B. eine React + Go + PostgreSQL App aus einem Chat-Interface in Koder.ai generierst), sind Ullman-artige Modelle ein praktisches Sicherheitsnetz: Du kannst das generierte Schema auf saubere Keys und Beziehungen prüfen, die Abfragen der App inspizieren und Performance mit EXPLAIN validieren, bevor Probleme in Produktion auftauchen. Je schneller du von „Abfrage-Absicht → Plan → Fix" iterierst, desto mehr Wert bring dir beschleunigte Entwicklung.

Wo du mehr lernen kannst und wie du es im Job anwendest

Du musst Theorie nicht als eigenes Hobby betreiben. Der schnellste Weg, von Ullman-Grundlagen zu profitieren, ist, gerade genug zu lernen, um Abfragepläne sicher zu lesen — und dann auf deiner eigenen Datenbank zu üben.

Anfängerfreundliche Ressourcen

Suche nach diesen Büchern und Vorlesungsthemen (keine Affiliation — nur verbreitete Einstiegsquellen):

• „A First Course in Database Systems" (Ullman & Widom) — zugängliche Datenbankgrundlagen mit praktischem Fokus.
• „Principles of Database and Knowledge-Base Systems" (Ullman) — tiefere Theorie, falls du mehr Rigor willst.
• „Compilers: Principles, Techniques, and Tools" (Aho, Lam, Sethi, Ullman) — für die Verbindung „warum ähneln Optimierer Compilern?".
• Vorlesungssuchen: relationale Algebra, Abfrageumschreibung, Join-Planung, kostenbasierte Optimierung, Indizes und Selektivität, Parsen und Abfragesprachen.

Ein leichter Lernpfad

Beginne klein und binde jeden Schritt an etwas Beobachtbares:

1. Relationale Algebra: lerne Selektion, Projektion, Join und Äquivalenzregeln.
2. Pläne: lerne Plan-Knoten (Scan-Typen, Filter, Joins, Sorts, Aggregationen) zu lesen.
3. Joins: verstehe Nested Loop vs. Hash Join vs. Merge Join und wann jeder gewinnt.
4. Kostenmodelle: lerne die Eingaben, die Entscheidungen treiben (Zeilenzahlen, Selektivität, I/O vs. CPU).

Kleine Übungen mit großem Effekt

Wähle 2–3 reale Abfragen und iteriere:

• Umschreiben: IN gegen EXISTS tauschen, Prädikate früher anwenden, unnötige Spalten entfernen und Ergebnisse vergleichen.
• Pläne vergleichen: "vorher/nachher"-Pläne aufnehmen und notieren, was sich geändert hat (Join-Reihenfolge, Join-Typ, Scan-Typ).
• Indizes variieren: einen Index hinzufügen/entfernen und geschätzte vs. tatsächliche Zeilen beobachten.

Erkenntnisse an Teamkollegen kommunizieren

Nutze klare, plan-basierte Sprache:

• „Der Plan wechselte von einem Sequential Scan zu einem Index Scan, weil der Filter selektiv wurde."
• „Die Zeilenschätzung war um 100× falsch, daher wählte der Optimierer die falsche Join-Reihenfolge."
• „Diese Umschreibung ist äquivalent (gleiches Ergebnis), aber ermöglicht Predicate Pushdown und weniger Zeilen in den Join."

Das ist der praktische Gewinn von Ullmans Grundlagen: Du erhältst ein gemeinsames Vokabular, um Performance zu erklären — ohne zu raten.