Wie entwerfen Sie Schemas in MongoDB?

Question

Accepted Answer

Das MongoDB-Schema-Design konzentriert sich auf eine Schlüsselentscheidung: **Embedding** (Speicherung zugehöriger Daten innerhalb eines Dokuments) vs. **Referencing** (Speicherung zugehöriger Daten in separaten Dokumenten/Sammlungen mit Verweisen). Im Gegensatz zu SQLs Normalisierung-by-default optimiert MongoDB-Design für die Art und Weise, wie auf die Daten *zugegriffen wird*.

## Embedding — verwandte Daten zusammen speichern

```js
// embed related data within the document
{
  _id: ObjectId("..."),
  name: "Ann",
  address: { city: "NY", zip: "10001" },        // embedded sub-document
  orders: [                                      // embedded array of orders
    { product: "Phone", amount: 999 },
    { product: "Case", amount: 20 }
  ]
}
// → ONE query gets the user AND their address AND orders (no joins)
```

**Embedding** behält verwandte Daten in einem Dokument — lesen Sie alles in einer einzelnen Abfrage (schnell, keine Joins). Gut für Daten, die zusammen zugegriffen werden, und "Enthält"-Beziehungen.

## Referencing — separate Dokumente verlinken

```js
// store a reference (id) to a document in another collection
{ _id: ObjectId("u1"), name: "Ann" }                          // users collection
{ _id: ObjectId("o1"), userId: ObjectId("u1"), product: "Phone" } // orders collection
// → query orders by userId; use $lookup to join when needed
```

**Referencing** speichert Daten separat und verlinkt per ID (wie ein Foreign Key) — Abfrage separat oder Join mit `$lookup`.

## Embedding vs. Referencing: Wann welches?

```text
EMBED when:
  ✓ data is accessed TOGETHER (read the parent → you want the children)
  ✓ a "contains"/ownership relationship (address, order line items)
  ✓ the embedded data is bounded (not unboundedly growing)
  ✓ one-to-few relationships

REFERENCE when:
  ✓ data is large or grows UNBOUNDEDLY (avoid huge documents — 16MB doc limit!)
  ✓ data is accessed/updated INDEPENDENTLY
  ✓ many-to-many or one-to-many with many
  ✓ the same data is shared/referenced by many documents (avoid duplication)
```

## Design für Zugriffsmuster (das Kernprinzip)

```text
MongoDB schema design is driven by HOW YOU QUERY the data, not pure normalization:
  → Structure data so common queries are efficient (often a single document read).
  → "Data that is accessed together should be stored together."
  → This may mean DENORMALIZING (some duplication) for read efficiency — acceptable
    in MongoDB, traded against update complexity.
```

## Warum es wichtig ist

Schema-Design ist entscheidend wichtig in MongoDB — es unterscheidet sich von SQL und ist möglicherweise folgenreicher als in SQL, da Mongodbs flexibles Dokumentmodell Ihnen Wahlmöglichkeiten bietet, die Leistung und Wartbarkeit erheblich beeinflussen. Daher ist das Verständnis dafür unverzichtbar für den Aufbau effektiver MongoDB-Anwendungen.

Die zentrale Entscheidung — **Embedding vs. Referencing** — ist die definierende MongoDB-Design-Wahl: **Embedding** (Speicherung verwandter Daten innerhalb eines Dokuments) ermöglicht schnelle Single-Query-Lesevorgänge verwandter Daten (keine Joins) und eignet sich für Daten, auf die zusammen zugegriffen wird, und "Enthält"-Beziehungen. **Referencing** (Verlinken separater Dokumente per ID) eignet sich für große/unbegrenzte Daten, unabhängig zugegriffene Daten und gemeinsame/viele Beziehungen.

Das Verständnis **wann man welche verwendet** (Embedding für begrenzte, zusammen zugegriffene, eigene Daten; Referencing für große/wachsende, unabhängige, gemeinsame oder viele Beziehungen — und Beachtung von Mongodbs 16MB-Dokumentgrößenlimit) ist die Schlüsselfähigkeit.

Am wichtigsten ist das Verständnis des leitenden Prinzips — **Design für Zugriffsmuster** (Strukturieren Sie Daten um die Art und Weise, wie Sie sie abfragen, damit häufige Abfragen effizient sind, oft ein einzelnes Dokument-Lesevorgang, statt standardmäßig wie SQL zu normalisieren) — das unterscheidet gutes MongoDB-Schema-Design.

Dies kann bedeuten, dass man etwas **Denormalisierung** (Duplizierung) für Leseeffizienz akzeptiert, ein Kompromiss gegen Update-Komplexität, der in MongoDB akzeptabel und oft korrekt ist.

Da Schema-Design MongoDB-Anwendungsleistung und Wartbarkeit tiefgreifend beeinflusst (eine schlechte Embedding/Referencing-Wahl verursacht langsame Abfragen, riesige Dokumente oder Update-Komplexität), und da der Zugriffsmuster-gesteuerte, Embedding-vs-Referencing-Ansatz grundlegend anders ist als SQL-Normalisierung, ist das Verständnis von MongoDB-Schema-Design — die Embedding/Referencing-Entscheidung, wann man welche verwendet, und Design für Zugriffsmuster — unverzichtbares, hocherwertiges Wissen für den Aufbau effektiver MongoDB-Anwendungen, eines der wichtigsten und charakteristischsten MongoDB-Themen, das diejenigen unterscheidet, die gute Dokumentschemas entwerfen, von denen, die naiv relationale Designs portieren.