Requêtes relationnelles (jointures) dans les bases documentaires

Une requête relationnelle en base documentaire est une jointure faite par références et lookups au lieu de clés étrangères — ou évitée en embarquant. Ce “ou” est tout le sujet : les bases documentaires vous offrent trois façons de relier des données, et la décision de conception porte sur le moment où la jointure a lieu — à l’écriture (embarquement), au moment de la requête côté serveur (lookup), ou au moment de la requête côté application (références plus une récupération de suivi).

Points clés

Les trois façons de relier des documents

// 1 · Embarquer — la "jointure" a eu lieu à l'écriture
{ _id: 1, title: "Dune", author: { name: "Frank Herbert", born: 1920 } }

// 2 · Référence + $lookup — la jointure a lieu à la requête, côté serveur
db.books.aggregate([
  { $lookup: { from: "authors", localField: "authorId",
               foreignField: "_id", as: "author" } },  // left outer join → tableau
  { $unwind: "$author" }                               // aplatir → inner join
])

// 3 · Référence + jointure côté application — la voie ODM/SDK (ci-dessous)

La troisième voie est celle où vit l’essentiel du code applicatif — des références typées parcourues par chargement anticipé (eager loading) en une seule requête, pour que les documents liés arrivent ensemble sans pipeline :

// JavaScript / Node.js — Back4app JS SDK
// A join in a document database: Pointer + include, one request
const query = new Parse.Query('Comment');
query.equalTo('post', postPointer);   // Comment.post is a Pointer<Post>
query.include('author');              // "join" the author document in
const comments = await query.find();

const name = comments[0].get('author').get('username'); // already loaded — no N+1

// Flutter / Dart — Back4app Flutter SDK
// A join in a document database: Pointer + include, one request
final query = QueryBuilder<ParseObject>(ParseObject('Comment'))
  ..whereEqualTo('post', postPointer)
  ..includeObject(['author']); // "join" the author document in
final response = await query.query();

final author = (response.results!.first as ParseObject)
    .get<ParseObject>('author'); // already loaded — no N+1

// iOS / Swift — Back4app Swift SDK
// A join in a document database: Pointer + include, one request
let query = Comment.query("post" == postPointer)
  .include("author") // "join" the author document in
query.find { result in
  if case .success(let comments) = result {
    print(comments.first?.author?.username ?? "") // already loaded — no N+1
  }
}

// Android / Kotlin — Back4app Android SDK
// A join in a document database: Pointer + include, one request
val query = ParseQuery.getQuery<ParseObject>("Comment")
query.whereEqualTo("post", postPointer)
query.include("author") // "join" the author document in
query.findInBackground { comments, e ->
  if (e == null) {
    val name = comments[0].getParseObject("author")?.getString("username")
    Log.d("Comments", "by $name") // already loaded — no N+1
  }
}

Embarquer vs. référencer : la décision

Les paliers de cardinalité donnent la même table sous forme de règles empiriques : un-à-quelques embarque le tableau, un-à-plusieurs référence par ID, un-à-énormément inverse le sens — l’enfant stocke la référence au parent, car aucun document parent ne peut contenir un tableau qui grossit sans cesse. Ce qui désigne les deux anti-patterns derrière la plupart des incidents de modélisation documentaire : les tableaux non bornés et le plafond de 16 Mo par document qu’ils finissent par menacer. Les correctifs standard — référencer à la place, embarquer un sous-ensemble borné (les N plus récents avec une collection de débordement), ou regrouper les enfants dans des documents-buckets — sont tous des variantes de “empêcher le document de grossir”.

Le lookup, en toute honnêteté

$lookup est une vraie jointure, avec deux astérisques honnêtes. La forme : il renvoie les correspondances sous forme de tableau embarqué pour chaque document en entrée — $unwind l’aplatit en lignes et, sans la sémantique de conservation des vides, transforme le comportement de left join en inner join. La performance : les moteurs documentaires n’exécutent que des jointures en boucles imbriquées, et les benchmarks publics sont sans appel — joindre un million de documents a pris des dizaines de secondes avec index, contre une demi-seconde pour l’équivalent embarqué. Les règles opérationnelles qui en découlent : indexez toujours le champ étranger (sans index, chaque document en entrée déclenche un parcours de collection), utilisez les lookups pour des jointures par requête sur une poignée de documents, et ne construisez jamais de fan-out analytique dessus — cette charge revient à un entrepôt de données ou à un moteur relationnel.

Le problème N+1 et ses quatre issues

Le bug classique : une requête pour N parents, puis une boucle qui émet une requête par parent pour ses enfants — N+1 allers-retours qui augmentent avec la taille de la page. Les issues, de la meilleure à la moins bonne : par lot (batch) — collectez les ID des parents et récupérez tous les enfants en une seule requête de type contained-in (le populate des bons ODM le fait pour vous) ; include — un eager loading au niveau du SDK qui renvoie les documents référencés dans la même requête, comme dans les onglets ci-dessus ; lookup — un seul pipeline côté serveur ; embarquement — la jointure cesse d’exister. Ce qui transforme le N+1 de bug en problème d’architecture, c’est de ne pas le remarquer : il passe sans encombre sur dix enregistrements de test et s’effondre à mille — la pathologie complète a sa propre entrée dans le registre de ce glossaire.

Cas d’usage courants

• Contenu avec auteurs. Posts, commentaires, auteurs — des références avec includes pour les vues en liste, de l’embarquement pour les champs d’instantané affichés en lecture seule.
• Catalogues et commandes. La référence étendue canonique : une commande embarque le nom et le prix du produit au moment de la vente (instantané immuable) plus une référence au produit vivant.
• Flux d’activité et d’événements. Un-à-énormément — des documents enfants qui portent la référence au parent, jamais de tableaux sur le parent.
• Profils utilisateur. La vitrine de l’embarquement : adresses, préférences, paramètres — lus ensemble, bornés, possédés.
• Graphes sociaux. Des tableaux de références plusieurs-à-plusieurs — et le signal honnête qu’au-delà d’un certain point, cette forme réclame un moteur relationnel ou orienté graphe.

Embarquer, référencer ou changer de moteur ? Matrice de décision

La troisième colonne est la section que les pages des éditeurs n’écriront pas : si chaque écran a besoin de trois lookups et que l’intégrité référentielle vous empêche de dormir, vos données réclament des tables — les modèles documentaires gagnent quand les patterns d’accès sont connus et hiérarchiques, pas comme remplacement universel.

Limites et trade-offs

• La dénormalisation est un instrument de dette. Les champs dupliqués suppriment des jointures mais se remboursent à la mise à jour — écritures en fan-out, fenêtres de données périmées et code de cohérence (transactions ou triggers sur change streams) en sont les intérêts.
• Pas de clés étrangères, pas de filet de sécurité. Les références ne garantissent pas l’existence ; supprimer un auteur laisse en silence des références orphelines dans les livres, à moins que votre plateforme ou votre code ne fasse le ménage.
• Les lookups ne s’optimisent pas. Aucun réordonnancement des jointures, aucune stratégie hash — l’ordre du pipeline est votre plan de requête.
• Les migrations entre formes sont de vrais projets. Passer de l’embarqué au référencé (le sauvetage du tableau qui grossit) implique de remplir rétroactivement des collections et de réécrire des requêtes — modélisez pour la cardinalité de demain, pas celle d’aujourd’hui.
• Le plafond de 16 Mo est une falaise, pas un avertissement. Les schémas de croissance qui s’en approchent dégradent la performance bien avant de l’atteindre.

Les requêtes relationnelles sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Sa base de données documentaire parle un vocabulaire relationnel par conception : les Pointers déclarent les arêtes un-à-plusieurs, les Relations gèrent le plusieurs-à-plusieurs, et include() parcourt les arêtes en une seule requête — l’issue au N+1 intégrée au SDK, comme le montrent les onglets de code ci-dessus. L’API GraphQL générée automatiquement imbrique gratuitement les objets liés en une seule requête, et les suppressions peuvent se propager en cascade via des triggers Cloud Code — le filet de sécurité d’intégrité référentielle que les moteurs documentaires laissent de côté.