Comment modélisez-vous les relations dans MongoDB ?

Question

Accepted Answer

MongoDB modélise les relations (un-à-un, un-à-plusieurs, plusieurs-à-plusieurs) par **imbrication** ou **référencement** — le choix dépend de la cardinalité de la relation, de la manière dont les données sont accédées, et si elles sont partagées. Contrairement à l'approche uniforme des clés étrangères de SQL, MongoDB offre de la flexibilité par relation.

## Un-à-un

```js
// usually EMBED (the related data belongs to the document)
{ _id: ObjectId("..."), name: "Ann", profile: { bio: "...", avatar: "..." } }
// → one query gets both; they're accessed together
```

## Un-à-plusieurs (le plus courant — et le plus nuancé)

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

La nuance clé : **un-à-peu** (imbrication), **un-à-plusieurs** (référencement du côté « plusieurs »), **un-à-zillions** (toujours référencer — ne jamais imbriques des données non bornées, en raison de la limite de 16 Mo par document et des problèmes de performance).

## Plusieurs-à-plusieurs

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

Les relations plusieurs-à-plusieurs utilisent des tableaux d'identifiants référencés (d'un ou des deux côtés), ou une collection de jonction séparée pour les données relationnelles enrichies.

## Résoudre les références ($lookup)

```js
// join referenced data when needed
db.books.aggregate([
  { $lookup: { from: "authors", localField: "authorId", foreignField: "_id", as: "author" } }
]);
```

## Pourquoi c'est important

La modélisation des relations est fondamentale à la conception de bases de données, et l'approche flexible de MongoDB guidée par les schémas d'accès est différente des clés étrangères uniformes de SQL ; comprendre comment modéliser les relations dans MongoDB est donc essentiel pour concevoir des schémas efficaces.

L'insight clé est que MongoDB modélise les relations par **imbrication ou référencement** en fonction des caractéristiques de la relation — et comprendre **comment la cardinalité affecte le choix** est la compétence cruciale : **un-à-un** (généralement imbrication — accédées ensemble), **un-à-plusieurs** avec ses nuances importantes (**un-à-peu** → imbrication pour les données bornées accédées ensemble ; **un-à-plusieurs** → référencement du côté « plusieurs » ; **un-à-zillions** → toujours référencer, ne jamais imbricher des données non bornées en raison de la limite de 16 Mo par document et des problèmes de performance), et **plusieurs-à-plusieurs** (tableaux d'identifiants référencés, ou une collection de jonction).

Cette prise de décision basée sur la cardinalité (en particulier la reconnaissance de quand les données sont trop volumineuses/non bornées pour être imbriquées) est essentielle pour éviter les erreurs courantes comme imbricher des tableaux non bornés (gonflant les documents, atteignant les limites) ou sur-référencer des données qui devraient être imbriquées.

Comprendre comment **résoudre les références** avec `$lookup` quand des jointures sont nécessaires complète le tableau.

Puisque les relations entre entités sont inhérentes à la plupart des modèles de données, et puisque l'approche flexible par relation de MongoDB (imbrication ou référencement basée sur la cardinalité et les schémas d'accès) est fondamentalement différente et plus nuancée que les clés étrangères uniformes de SQL, comprendre comment modéliser les relations dans MongoDB — les décisions d'imbrication/référencement basées sur la cardinalité (en particulier la distinction un-à-peu/plusieurs/zillions) et la résolution des références — est une connaissance essentielle et fréquemment appliquée pour une conception de schéma MongoDB efficace, s'appuyant sur les fondamentaux d'imbrication/référencement pour gérer les relations que chaque application réelle possède, et un domaine clé distinguant la modélisation MongoDB solide des ports naïfs relationnels.