MongoDB modelliert Beziehungen (one-to-one, one-to-many, many-to-many) durch Embedding oder Referencing — die Wahl hängt von der Kardinalität der Beziehung, der Zugriffsmuster auf die Daten und davon ab, ob die Daten geteilt werden. Im Gegensatz zu SQLs einheitlichem Foreign-Key-Ansatz bietet MongoDB Flexibilität pro Beziehung.
{ : (), : , : { : , : } }
// ONE-TO-FEW → embed (bounded, accessed together)
{ _id: ObjectId("..."), name: "Ann", addresses: [ {...}, {...} ] } // a few addresses
// ONE-TO-MANY → reference (the "many" side references the "one")
// authors collection: { _id: "a1", name: "Ann" }
// books collection: { _id: "b1", authorId: "a1", title: "..." } // each book references its author
// ONE-TO-SQUILLIONS (huge/unbounded) → ALWAYS reference (never embed unbounded data)
// e.g. a user with millions of log entries → separate collection, reference by userId
Die wichtige Nuance: one-to-few (embed), one-to-many (reference von der many-Seite), one-to-squillions (immer reference — niemals unbegrenzte Daten einbetten, aufgrund des 16MB-Dokumentenlimits und Performance).
// reference with an array of ids (on one or both sides)
{ _id: "s1", name: "Student", courseIds: ["c1", "c2"] } // student → courses
{ _id: "c1", name: "Course", studentIds: ["s1", "s2"] } // course → students (optional)
// → query and $lookup to resolve; or a separate "enrollments" collection (junction-like)
Many-to-many nutzt Arrays von referenzierten IDs (auf einer oder beiden Seiten) oder eine separate junction-ähnliche Collection für umfangreiche Beziehungsdaten.
// join referenced data when needed
db.books.aggregate([
{ $lookup: { from: "authors", localField: "authorId", foreignField: "_id", as: "author" } }
]);
Das Modellieren von Beziehungen ist grundlegend für Datenbankdesign, und Mongodbs flexibler, zugriffsmuster-getriebener Ansatz unterscheidet sich von SQLs einheitlichen Foreign Keys. Daher ist es wesentlich zu verstehen, wie man Beziehungen in MongoDB modelliert, um effektive Schemas zu gestalten.
Die Kernidee ist, dass MongoDB Beziehungen durch Embedding oder Referencing basierend auf den Charakteristiken der Beziehung modelliert — und das Verständnis von wie die Kardinalität die Wahl beeinflusst, ist die entscheidende Fähigkeit: one-to-one (gewöhnlich embed — zusammen zugegriffen), one-to-many mit seinen wichtigen Nuancen (one-to-few → embed für begrenzte zusammen zugegriffene Daten; one-to-many → reference von der many-Seite; one-to-squillions → immer reference, niemals unbegrenzte Daten einbetten aufgrund des 16MB-Dokumentenlimits und Performance), und many-to-many (Arrays von referenzierten IDs oder eine junction-ähnliche Collection).
Diese kardinalitäts-getriebene Entscheidungsfindung (insbesondere erkennen, wenn Daten zu groß/unbegrenzt sind, um sie einzubetten) ist wesentlich, um häufige Fehler wie das Einbetten unbegrenzter Arrays (aufgeblähte Dokumente, Limits erreichen) oder Überreferenzierung von Daten, die eingebettet sein sollten, zu vermeiden.
Das Verständnis, wie man Referenzen auflöst mit $lookup, wenn Joins benötigt werden, vervollständigt das Bild.
Da Beziehungen zwischen Entitäten in den meisten Datenmodellen inhärent sind, und da Mongodbs flexibler pro-Beziehungs-Ansatz (embed vs reference basierend auf Kardinalität und Zugriffsmuster) grundlegend anders und differenzierter als SQLs einheitliche Foreign Keys ist, ist das Verständnis, wie man Beziehungen in MongoDB modelliert — die kardinalitäts-basierten embed/reference-Entscheidungen (insbesondere die one-to-few/many/squillions-Unterscheidung) und das Auflösen von Referenzen — wesentlich, häufig angewendetes Wissen für effektives MongoDB-Schema-Design, aufbauend auf den embed/reference-Grundlagen, um die Beziehungen, die jede echte Anwendung hat, zu bewältigen, und ein Schlüsselbereich, der soundes MongoDB-Modeling von naiven relationalen Ports unterscheidet.