Relationale Abfragen (Joins) in Dokumentdatenbanken

Eine relationale Abfrage in einer Dokumentdatenbank ist ein Join über Referenzen und Lookups statt Fremdschlüssel – oder wird durch Einbetten vermieden. Dieses “oder” ist das ganze Thema: Dokumentdatenbanken bieten drei Wege, Daten in Beziehung zu setzen, und die Entwurfsentscheidung betrifft den Zeitpunkt des Joins – beim Schreiben (Einbetten), zur Abfragezeit im Server (Lookup) oder zur Abfragezeit in der Anwendung (Referenzen plus ein zweiter Ladevorgang).

Das Wichtigste in Kürze

Die drei Wege, Dokumente zu verbinden

// 1 · Einbetten — der "Join" fand beim Schreiben statt
{ _id: 1, title: "Dune", author: { name: "Frank Herbert", born: 1920 } }

// 2 · Referenz + $lookup — der Join findet zur Abfragezeit statt, serverseitig
db.books.aggregate([
  { $lookup: { from: "authors", localField: "authorId",
               foreignField: "_id", as: "author" } },  // Left Outer Join → Array
  { $unwind: "$author" }                               // flach ziehen → Inner Join
])

// 3 · Referenz + Join in der Anwendung — der ODM/SDK-Weg (unten)

Der dritte Weg ist der, auf dem der meiste Anwendungscode lebt – typisierte Referenzen, in einer Anfrage vorausgeladen, sodass verwandte Dokumente ohne Pipeline gemeinsam ankommen:

// JavaScript / Node.js — Back4app JS SDK
// A join in a document database: Pointer + include, one request
const query = new Parse.Query('Comment');
query.equalTo('post', postPointer);   // Comment.post is a Pointer<Post>
query.include('author');              // "join" the author document in
const comments = await query.find();

const name = comments[0].get('author').get('username'); // already loaded — no N+1

// Flutter / Dart — Back4app Flutter SDK
// A join in a document database: Pointer + include, one request
final query = QueryBuilder<ParseObject>(ParseObject('Comment'))
  ..whereEqualTo('post', postPointer)
  ..includeObject(['author']); // "join" the author document in
final response = await query.query();

final author = (response.results!.first as ParseObject)
    .get<ParseObject>('author'); // already loaded — no N+1

// iOS / Swift — Back4app Swift SDK
// A join in a document database: Pointer + include, one request
let query = Comment.query("post" == postPointer)
  .include("author") // "join" the author document in
query.find { result in
  if case .success(let comments) = result {
    print(comments.first?.author?.username ?? "") // already loaded — no N+1
  }
}

// Android / Kotlin — Back4app Android SDK
// A join in a document database: Pointer + include, one request
val query = ParseQuery.getQuery<ParseObject>("Comment")
query.whereEqualTo("post", postPointer)
query.include("author") // "join" the author document in
query.findInBackground { comments, e ->
  if (e == null) {
    val name = comments[0].getParseObject("author")?.getString("username")
    Log.d("Comments", "by $name") // already loaded — no N+1
  }
}

Einbetten vs. Referenzieren: die Entscheidung

Die Kardinalitätsstufen ergeben dieselbe Tabelle als Faustregeln: Eins-zu-wenige bettet das Array ein, Eins-zu-viele referenziert per ID, Eins-zu-riesig dreht die Richtung um – das Kind speichert die Referenz auf das Elternobjekt, weil kein Elterndokument ein unaufhörlich wachsendes Array halten kann. Damit sind auch die beiden Anti-Patterns benannt, die hinter den meisten Zwischenfällen bei der Dokumentmodellierung stehen: unbegrenzte Arrays und die 16-MB-Grenze pro Dokument, die sie irgendwann bedrohen. Die üblichen Auswege – stattdessen referenzieren, eine begrenzte Teilmenge einbetten (die neuesten N plus eine Überlauf-Collection) oder Kinder in gruppierte Dokumente bündeln – sind allesamt Varianten von “das Dokument am Wachsen hindern”.

Der Lookup, ehrlich betrachtet

$lookup ist ein echter Join mit zwei ehrlichen Sternchen. Zur Form: Er liefert Treffer als eingebettetes Array pro Eingabedokument – $unwind zieht es zu Zeilen flach und verwandelt ohne Preserve-Empty-Semantik das Left-Join- in Inner-Join-Verhalten. Zur Performance: Dokument-Engines führen ausschließlich Nested-Loop-Joins aus, und öffentliche Benchmarks sind unmissverständlich – der Join über eine Million Dokumente dauerte mit Indizes mehrere Dutzend Sekunden, gegenüber einer halben Sekunde für das eingebettete Äquivalent. Daraus folgen die Betriebsregeln: das Fremdfeld immer indizieren (ohne Index löst jedes Eingabedokument einen Collection-Scan aus), Lookups für Joins pro Anfrage über eine Handvoll Dokumente einsetzen und niemals analytische Fan-outs darauf bauen – diese Last gehört in ein Data Warehouse oder eine relationale Engine.

Das N+1-Problem und seine vier Auswege

Der klassische Fehler: eine Abfrage für N Elternobjekte, dann eine Schleife, die pro Elternobjekt eine Abfrage für dessen Kinder absetzt – N+1 Roundtrips, die mit der Seitengröße skalieren. Die Auswege, der beste zuerst: Batching – die Eltern-IDs sammeln und alle Kinder in einer “enthalten-in”-Abfrage holen (das populate guter ODMs erledigt das für Sie); Include – Eager Loading auf SDK-Ebene, das die referenzierten Dokumente in derselben Anfrage zurückgibt, wie in den Tabs oben; Lookup – eine serverseitige Pipeline; Einbetten – der Join hört auf zu existieren. Was N+1 vom Fehler zur Architektur macht, ist, es nicht zu bemerken: Auf zehn Testdatensätzen geht es glatt durch und bei tausend schmilzt es weg – die vollständige Pathologie hat einen eigenen Eintrag im Register dieses Glossars.

Typische Anwendungsfälle

• Inhalte mit Urheberschaft. Beiträge, Kommentare, Autoren – Referenzen mit Includes für die Listenansichten, Einbettungen für die reinen Anzeige-Schnappschussfelder.
• Kataloge und Bestellungen. Der kanonische Fall der erweiterten Referenz: Eine Bestellung bettet Produktname und Verkaufspreis ein (unveränderlicher Schnappschuss) und hält zusätzlich eine Referenz auf das lebende Produkt.
• Aktivitäts- und Ereignisströme. Eins-zu-riesig – Kinddokumente halten Referenzen auf das Elternobjekt, niemals Arrays am Elternobjekt.
• Benutzerprofile. Das Paradebeispiel fürs Einbetten: Adressen, Präferenzen, Einstellungen – zusammen gelesen, begrenzt, eindeutig zugehörig.
• Soziale Graphen. Viele-zu-viele-Referenz-Arrays – und das ehrliche Signal, dass diese Form ab einem gewissen Punkt eine relationale oder eine Graph-Engine will.

Einbetten, referenzieren oder Engine wechseln? Eine Entscheidungsmatrix

Die dritte Spalte ist der Abschnitt, den Herstellerseiten nicht schreiben werden: Wenn jeder Bildschirm drei Lookups braucht und referenzielle Integrität Sie nachts wachhält, verlangen die Daten nach Tabellen – Dokumentmodelle gewinnen, wenn die Zugriffsmuster bekannt und hierarchisch sind, nicht als universeller Ersatz.

Grenzen und Trade-offs

• Denormalisierung ist ein Schuldschein. Duplizierte Felder sparen Joins, müssen aber bei jedem Update zurückgezahlt werden – Fan-out-Schreibvorgänge, Fenster mit veralteten Daten und Konsistenzcode (Transaktionen oder Change-Stream-Trigger) sind die Zinsen.
• Keine Fremdschlüssel, kein Sicherheitsnetz. Referenzen erzwingen keine Existenz; wer einen Autor löscht, hinterlässt stillschweigend verwaiste Buchreferenzen, solange Plattform oder Code nicht aufräumen.
• Lookups optimieren nicht. Kein Umsortieren von Joins, keine Hash-Strategien – die Reihenfolge der Pipeline ist Ihr Abfrageplan.
• Migrationen zwischen den Formen sind echte Projekte. Von eingebettet zu referenziert (die Rettung des wachsenden Arrays) heißt, Collections nachzufüllen und Abfragen neu zu schreiben – modellieren Sie für die Kardinalität von morgen, nicht die von heute.
• Die 16-MB-Grenze ist eine Klippe, keine Warnung. Wachstumsmuster, die sich ihr nähern, verschlechtern die Performance lange, bevor sie sie erreichen.

Relationale Abfragen mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Ihre Dokumentdatenbank spricht von Haus aus ein relationales Vokabular: Pointers deklarieren Eins-zu-viele-Kanten, Relations übernehmen Viele-zu-viele, und include() geht die Kanten in einer einzigen Anfrage ab – der N+1-Ausweg, fest im SDK eingebaut, wie die Code-Tabs oben zeigen. Die automatisch generierte GraphQL-API verschachtelt verwandte Objekte gratis in einer Abfrage, und Löschungen können über Cloud-Code-Trigger kaskadieren – das Sicherheitsnetz für referenzielle Integrität, das Dokument-Engines auslassen.