Chapitre 08 — Modéliser une base

1 Principe

Embarquer ou référencer ?

Deux façons de relier des données :

Embarquer — imbriquer les données liées dans le document parent (un sous-document ou un tableau).
Référencer — stocker seulement l'_id de l'autre document, comme une clé étrangère.

La règle d'or :

« Ce qu'on lit ensemble, on le stocke ensemble. » On embarque les données quasiment toujours consultées avec leur parent et qui lui appartiennent ; on référence ce qui est partagé, volumineux, ou qui vit sa propre vie.

2 Relation

Un-à-un (1‑1)

Une entité liée à exactement une autre : le plus souvent on embarque, sous forme de sous-document.

{
  "nom": "Dupont",
  "adresse": {            // sous-document embarqué (1-1)
    "rue": "3 rue des Tilleuls",
    "ville": "Limoges",
    "cp": "87000"
  }
}

3 Relation

Un-à-plusieurs (1‑N) — embarqué

Quand les « plusieurs » appartiennent au parent et ne sont pas trop nombreux, on les embarque dans un tableau.

{
  "zone": "Ladignac-le-Long",
  "commandes": [                 // tableau embarqué (1-N)
    { "litres": 1500, "commune": "Ladignac" },
    { "litres": 800,  "commune": "Nexon" }
  ]
}

Avantage — une seule lecture ramène la campagne et ses commandes. Pas de jointure.

4 Relation

Un-à-plusieurs (1‑N) — référencé

Quand les « plusieurs » sont très nombreux, partagés, ou consultés séparément, on référence : le parent (ou l'enfant) stocke l'_id de l'autre.

// une campagne référence son fournisseur (partagé par plusieurs campagnes)
{ "zone": "Ladignac-le-Long", "fournisseurId": "total-energies" }

{ "_id": "total-energies", "nom": "TotalEnergies", "paliers": [ ... ] }

Reconstituer le lien — côté requête, on joint avec $lookup (chapitre 14) ou on fait deux lectures. Côté Spring, ce sera une relation par identifiant entre deux repositories.

5 Relation

Plusieurs-à-plusieurs (N‑N)

On modélise avec des tableaux d'identifiants d'un côté (ou des deux), sans table de jonction comme en SQL.

// un fournisseur dessert plusieurs zones ; une zone a plusieurs fournisseurs
{ "_id": "total-energies", "zonesDesservies": ["87", "19", "23"] }

À retenir — on choisit le côté où placer le tableau selon les requêtes les plus fréquentes (« quelles zones pour ce fournisseur ? » vs « quels fournisseurs pour cette zone ? »).

6 Règles

Limites & bonnes pratiques

16 Mo — un document ne peut pas dépasser 16 Mo. Un tableau qui grossit sans fin (des milliers d'éléments) doit être référencé, pas embarqué.
Dénormalisation maîtrisée — on accepte parfois de dupliquer une donnée (ex. le nom du fournisseur dans la campagne) pour éviter une jointure à chaque lecture ; en contrepartie, il faut la mettre à jour aux deux endroits.
Modéliser d'après les accès — on part des écrans et des requêtes fréquentes, pas d'un schéma théorique.

🛢️ Sur le projet Fioul Groupé

Le modèle du projet découle directement de ce chapitre : commandes embarquées dans la campagne (on les lit toujours ensemble, volume raisonnable), fournisseur référencé (partagé, avec ses paliers), utilisateurs dans leur propre collection (ils se connectent, ont des rôles). Écris ce modèle et justifie chaque choix dans le README — c'est le jalon fil rouge du parcours MongoDB.

Ce qu'il faut retenir du chapitre

Question centrale : embarquer (lu ensemble, possédé) vs référencer (partagé, volumineux).
1‑1 : sous-document. 1‑N : tableau embarqué ou référence selon le volume.
N‑N : tableaux d'_id.
Limite 16 Mo ; dénormalisation maîtrisée ; modéliser d'après les accès.