SQL ou NoSQL ? Quel différence de modèle de données

Dans mon livre, j'émets l'idée que pour faire son choix de moteur de base de données, il est judicieux de partir de la donnée elle-même. Ce qui paraît très évident. Dans cet article, je vous propose un extrait du deuxième chapitre. J'ai remanié le texte pour qu'il soit plus ramassé et qu'il aille à l'essentiel.

Le modèle relationnel est basé sur un modèle mathématique. Les données sont organisées logiquement sous forme de tables et sont fortement structurées dans un modèle contraignant. L'avantage est de pouvoir leur appliquer des opérations algébriques et logiques, le désavantage est de forcer des données parfois plus complexes à se plier à cette structure.

De son côté, le mouvement NoSQL se base plutôt sur des expérimentations pratiques pour répondre à des besoins concrets. Souvent, le développement d'un moteur NoSQL est orienté vers la résolution d'une problématique particulière (montée en charge par exemple) à l'aide de technologies déjà existantes. Il s'agit plus souvent d'un travail d'ingénieur que d'un travail de chercheur.

L'agrégat

Martin Fowler, dans son livre « NoSQL distilled », reprend un concept d’Éric Evans, le créateur du Domain Driven Design, qu'il a appelé l'agrégat. Dans une conception orientée objet, un agrégat est une collection d’objets qui sont liés par une entité racine, nommée la racine de l’agrégat. L’agrégat permet de créer une unité d’information complexe qui est traitée, stockée, échangée de façon atomique. De l’extérieur, on ne peut faire référence à l’agrégat que par sa racine.

C’est un concept intéressant pour le programmeur parce qu’il permet d’assurer l’unité et l’intégrité d’un bloc d’informations en identifiant une racine, on pourrait dire une clé, et en permettant la référence uniquement sur cette clé. C’est un concept qui permet également de modéliser des éléments qu’on trouve dans la réalité. Par exemple, un magazine peut être vu comme une unité, qui contient des pages, les articles, des illustrations, un contenu riche et complexe, mais qui n’existe pas indépendamment du magazine lui-même. Pour y faire référence, vous faites référence au magazine. Pour lire un article, vous devez prendre le magazine et l’ouvrir. La racine représente donc le point d’entrée à ce bloc d’informations.

Dessin d'Olivier Ricol pour l'article

Une base de données orientée documents comme MongoDB stocke des données sous forme d’agrégats. Le document JSON contient un bloc d’information, une clé qui permet de l’identifier uniquement dans la collection des documents, et la manipulation du contenu du document se fait à la base en extrayant le document du moteur pour le manipuler dans son intégralité et le stocker à nouveau dans son intégralité.

Le modèle relationnel

Une base de données relationnelle ne structure pas du tout ses données en agrégats. Toute la structure des tables et des relations est à plat, et lorsque nous écrivons une requête SQL avec des jointures, nous exprimons dans la requête un agrégat que nous formons à partir des données des tables. Nous prenons la décision de partir d’une table spécifique, et nous exprimons par les jointures l’agrégat dont cette table est la racine (par exemple en partant d'un contact, en ajoutant ses factures, puis les produits commandés...).

On peut donc à partir d’un modèle relationnel, créer dynamiquement les agrégats souhaités à partir de n’importe quelle racine, de n’importe quel point d’entrée.

La centralité de la donnée

Le modèle relationnel est donc souple, il permet de servir plusieurs besoins applicatifs. Comme chaque application a besoin d’un agrégat différent, sa structure « plate » permet de reconstituer les agrégats demandés par chaque application. Par exemple, une base de données de gestion d’entreprise va permettre de satisfaire les applications des différents services : la logistique, la comptabilité, la relation client, la gestion des stocks qui voudront manipuler les données par des agrégats sur les commandes, les factures, identité du client, le produit.

Par contre, si l’agrégat est déjà formé dans la structure de la base de données, comme c’est le cas dans un moteur orienté documents, il sera plus naturellement enclin à satisfaire un besoin applicatif, mais pas tous les besoins.

Il y a donc dans les bases de données relationnelles une centralité plus forte de la donnée par rapport aux applications, et une seule base de données pourra être le point de convergence de plusieurs processus d’application de l’entreprise. Martin Fowler l’explique de la façon suivante : les bases de données relationnelles sont des outils d’intégration. Ils ont été utilisés par les projets informatiques pour faire converger les diverses applications client vers un seul point.

Si on abandonne l’idée du moteur de base de données unique qui centralise les besoins de toutes les applications, on peut alors choisir différents moteurs selon ses besoins, mais on doit alors considérer la duplication des données, l’échange et la transformation de ces données, bref une couche supplémentaire d’intégration, qu’il faut concevoir, développer, maintenir, avec les contraintes d’architecture, de développement, de performances et bien sûr d’intégrité. On s'approche de la conception orientée services.

Le modèle et la réalité

Pour penser et schématiser la réalité, nous avons besoin de modèles. Par exemple, pour penser la matière, nous avons bâti un modèle des atomes qui correspond à de petits systèmes stellaires. Mais cette représentation n'est pas fidèle à la réalité, c'est un modèle qui nous permet de la représenter. Le modèle relationnel et le modèle en agrégat ne sont pas plus juste l'un que l'autre, ils peuvent remplir leur office pour des besoins d'architecture différents.

Le modèle relationnel est seulement un modèle, ce n’est pas une vérité objective et naturelle. Il permet beaucoup de chose, mais il n’est pas la vérité révélée et il n’est pas infaillible. Il est facile d’en dénigrer d’autres juste parce qu’on a pris l’habitude d’un modèle. D’autre part, le modèle relationnel a de nombreuses qualités, et il serait idiot de le remplacer aveuglément par autre chose simplement pour satisfaire un goût de la nouveauté. En fait, le mouvement NoSQL n’est pas une révolution au sens politique du terme : le remplacement d’un ancien régime par un nouveau. On sait en général que ce type de radicalisme s’accompagne d’aveuglement. C’est une évolution. À la place d’un modèle hégémonique, qui nous oblige à le choisir en toutes circonstances, on obtient quelque chose de plus riche: le choix.