Choisir sa base de données : relationnel, document, ou les deux

C’est un choix qu’on fait au début d’un projet, qu’on ne refait presque jamais, et qui détermine une grande partie de ce qui sera facile ou pénible pendant huit ans.

Notre position par défaut est claire : relationnel, sauf raison précise de faire autrement. Voici le raisonnement, et les cas où nous en sortons.

Ce qu’une base relationnelle fait pour vous

Le point qui décide n’est pas le langage de requête ni la performance. C’est l’intégrité.

Dans une base relationnelle, on déclare des règles : une commande doit référencer un client existant, un montant ne peut pas être nul, un numéro de facture est unique. Ces règles sont appliquées par le moteur, à chaque écriture, quelle que soit son origine — l’application, un script de reprise, une correction manuelle un dimanche soir.

C’est cette dernière partie qui compte. Une règle implémentée dans le code applicatif protège les écritures qui passent par ce code. Au bout de quelques années, ce n’est plus vrai : un traitement par lot, un import, un correctif écrit dans l’urgence contournent la règle sans que personne ne s’en aperçoive.

La dégradation est silencieuse et cumulative. On la découvre le jour où un rapport donne un résultat incohérent, et il faut alors remonter des années d’écritures pour comprendre.

À cela s’ajoutent les transactions : plusieurs écritures qui réussissent ou échouent ensemble. Dès qu’une opération métier touche deux tables — débiter un stock et créer une commande — c’est indispensable, et cela s’obtient sans rien écrire.

Quand une base documentaire est le bon choix

Elle l’est, et je ne veux pas caricaturer le débat. Trois situations claires.

Des documents autonomes, sans relations fortes. Des fiches produit dont chacune a sa propre structure, des contenus éditoriaux, des configurations. Quand rien ne référence rien, la contrainte relationnelle n’apporte rien et la souplesse du document est un vrai gain.

Une structure variable et imprévisible. Des relevés de capteurs dont les champs diffèrent selon le modèle, des réponses d’API tierces qu’on veut conserver telles quelles. Modéliser cela en tables produit soit des dizaines de colonnes vides, soit une table clé-valeur qui reconstitue un document en moins bien.

Des volumes et un débit que le relationnel ne tient plus. Cela existe. C’est simplement beaucoup plus rare qu’on ne le croit, et cela concerne rarement les applications métier.

La question du volume arrive trop tôt

C’est l’argument le plus fréquemment avancé pour écarter le relationnel, et il est presque toujours prématuré.

Une base relationnelle correctement indexée, sur une machine ordinaire, traite sans difficulté des dizaines de millions de lignes. La très grande majorité des applications métier ne franchissent jamais ce seuil, y compris après dix ans d’exploitation.

Quand un projet ralentit sur des volumes bien inférieurs, la cause est presque toujours l’une des trois suivantes : un index manquant, une requête qui charge tout pour n’afficher qu’une page, ou une multiplication de requêtes dans une boucle. Changer de moteur ne corrige aucune des trois — on retrouve exactement le même problème ailleurs, avec en prime la perte des garanties.

Ma règle : on ne choisit pas une base de données sur des volumes hypothétiques. On la choisit sur la nature des données, et on traite la performance quand elle se manifeste, avec des mesures.

Photo : domaine public (CC0).

La combinaison, qui est souvent la meilleure réponse

Le débat « relationnel contre document » est largement dépassé, parce que les moteurs relationnels modernes stockent et interrogent nativement des documents structurés.

Cela permet une organisation que nous utilisons très souvent : le noyau métier en tables, les parties variables en documents, dans la même base.

Concrètement : la commande, le client, la facture et leurs relations vivent dans des tables avec toutes les contraintes. La réponse brute d’un service tiers, une configuration propre à un client ou un formulaire dont les champs changent selon le contexte vivent dans une colonne document.

On garde l’intégrité là où elle protège, la souplesse là où elle sert, une seule base à sauvegarder et une seule transaction pour écrire les deux. C’est presque toujours plus simple que de faire cohabiter deux moteurs.

Ce qu’on paye quand on fait cohabiter deux bases

Parce que cela arrive, et parfois à raison.

La cohérence entre les deux. Il n’y a plus de transaction commune : une écriture peut réussir d’un côté et échouer de l’autre. Il faut alors du code de rattrapage, et ce code est difficile à tester.

Deux exploitations. Deux systèmes de sauvegarde, deux restaurations à tester, deux montées de version, deux jeux de compétences dans l’équipe.

Une question sans réponse évidente : où est la vérité ? Quand la même information existe des deux côtés, il faut une règle claire, écrite, sur qui fait foi. Sans elle, chaque incident commence par une enquête.

Ces coûts sont réels et acceptables quand le besoin est réel. Ils ne le sont pas quand la deuxième base a été introduite pour un usage marginal.

Photo : Patrik Goethe — licence CC0.

Ce que je regarde avant de trancher

Quatre questions, dans cet ordre.

Les données ont-elles des relations qui doivent être garanties ? Si oui, relationnel. C’est le critère qui décide dans neuf cas sur dix.

La structure est-elle stable ? Un modèle qui change à chaque client est un signal en faveur du document — ou, plus souvent, le signe que le modèle n’a pas encore été compris.

Qui exploitera cette base dans cinq ans ? Une technologie que l’équipe en place ne maîtrise pas est un risque d’exploitation, pas seulement un choix technique.

Que se passe-t-il si une écriture se perd ? Sur des relevés de mesure, c’est sans gravité. Sur une écriture comptable, c’est inacceptable — et cela ferme le débat.

Les migrations de schéma, souvent oubliées dans l’arbitrage

Un argument revient en faveur du document : « avec le relationnel, il faut migrer le schéma à chaque changement ». C’est vrai, et c’est un avantage plutôt qu’un coût.

Une migration relationnelle est un fichier versionné, rejoué à l’identique sur chaque environnement. Elle est explicite, relue, et réversible si elle a été écrite pour l’être. À tout instant, on sait exactement quelle forme ont les données.

En documentaire, ce travail ne disparaît pas — il se déplace dans le code applicatif, qui doit savoir lire l’ancienne forme et la nouvelle. Au bout de trois ans, ce code accumule les branches de compatibilité, et plus personne ne sait quelles formes coexistent réellement en base.

La souplesse est réelle au démarrage. Elle se paye en lisibilité, et elle se paye au moment où l’on doit reprendre les données pour une analyse ou une migration.

Le conseil que je donne le plus souvent

Commencer en relationnel, y compris en cas de doute.

La raison est asymétrique : sortir d’un modèle relationnel bien conçu vers du document est un travail mécanique, parce que la structure est explicite et documentée par le schéma lui-même. L’inverse — reconstruire des contraintes sur plusieurs années de documents hétérogènes — est un chantier d’archéologie, où l’on découvre que trois générations de code ont écrit trois formes différentes du même objet.

Le choix par défaut doit être celui dont on peut revenir. Sur ce critère, le relationnel gagne largement.