Comment concevoir des schémas dans MongoDB ?

Question

Accepted Answer

La conception de schémas MongoDB se concentre sur une décision clé : **l'imbrication** (stocker les données associées à l'intérieur d'un document) par rapport au **référencement** (stocker les données associées dans des documents/collections séparés avec des références). Contrairement à la normalisation par défaut de SQL, la conception MongoDB optimise la façon dont les données sont *accessibles*.

## Imbrication — stocker les données associées ensemble

```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)
```

**L'imbrication** conserve les données associées dans un document — lisez-les tout en une seule requête (rapide, pas de jointures). Bien pour les données accessibles ensemble et les relations « contient ».

## Référencement — lier des documents séparés

```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
```

**Le référencement** stocke les données séparément et les lie par id (comme une clé étrangère) — interrogez séparément ou joignez avec `$lookup`.

## Quand imbriquer par rapport au référencement

```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)
```

## Concevoir pour les modèles d'accès (le principe clé)

```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.
```

## Pourquoi c'est important

La conception de schémas est critiquement importante dans MongoDB — elle est différente et potentiellement plus importante que dans SQL, car le modèle de document flexible de MongoDB vous offre des choix qui affectent considérablement la performance et la maintenabilité, donc la comprendre est essentielle pour construire des applications MongoDB efficaces.

La décision centrale — **imbrication par rapport au référencement** — est le choix de conception MongoDB définisseur : **l'imbrication** (stocker les données associées dans un document) permet des lectures rapides en une seule requête de données associées (pas de jointures) et convient aux données accessibles ensemble et aux relations « contient », tandis que **le référencement** (lier des documents séparés par id) convient aux données volumineuses/illimitées, aux données accessibles indépendamment, et aux relations partagées/multiples.

Comprendre **quand utiliser chacun** (imbriquer pour les données délimitées, accessibles ensemble, possédées ; référencer pour les données volumineuses/croissantes, indépendantes, partagées, ou multiples — et être conscient de la limite de taille de document de 16 Mo de MongoDB) est la compétence clé.

Le plus important, comprendre le principe directeur — **concevoir pour les modèles d'accès** (structurer les données autour de *la façon dont vous les interrogez*, afin que les requêtes courantes soient efficaces, souvent une lecture d'un seul document, plutôt que de normaliser par défaut comme SQL) — est ce qui distingue une bonne conception de schémas MongoDB.

Cela peut signifier accepter une certaine **dénormalisation** (duplication) pour l'efficacité en lecture, un compromis face à la complexité de mise à jour qui est acceptable et souvent correct dans MongoDB.

Étant donné que la conception de schémas affecte profondément la performance et la maintenabilité des applications MongoDB (un mauvais choix d'imbrication/référencement cause des requêtes lentes, des documents énormes, ou une complexité de mise à jour), et comme l'approche orientée par les modèles d'accès, d'imbrication par rapport au référencement est fondamentalement différente de la normalisation SQL, comprendre la conception de schémas MongoDB — la décision d'imbrication/référencement, quand utiliser chacun, et concevoir pour les modèles d'accès — est essentielle, une connaissance de haute valeur pour construire des applications MongoDB efficaces, l'un des sujets MongoDB les plus importants et distinctifs qui sépare ceux qui conçoivent de bons schémas de documents de ceux qui portent naïvement les designs relationnels.