Il y a une bonne dizaine d’années, un de mes amis et collègue, Samuel, a imaginé une représentation pour les identifiants d’entités et de services, qui sont simples, et particulièrement pratiques. Je vais vous les présenter ici mais tout d’abord, parlons un peu de modélisation.

La bonne vieille modélisation de grand-papa

Il existe de nombreuses théories mais souvent elles se ressemblent toutes. On a Merise de nos amis français, on a l’UML ou encore les diagrammes ER, etc. Dans le fond, c’est toujours la même idée. On crée des relations entre des entités et on se pose la question suivante :

Est-ce que j’ai une relation 1-1 ou n-n (1-n, n-1, 0-n, etc.) ?

En français :

Est-ce que mon entité doit avoir un lien avec une seule entité étrangère ou à une collection d’entités ?

Selon les outils, les langages, etc., il y a différentes façons de le faire mais contentons-nous de quelques diagrammes très simples qui permettent de résumer très rapidement de quoi on parle.

---

Une clef étrangère permet de référencer B depuis A.

---

Une table d’allocation permet de relier les A avec les B.

---

J’utilise le terme “table d’allocation” qui vient de Merise. Mais on peut aussi parler de table de relations, de liens, de correspondances, ou que sais-je. Ce n’est pas très important ici. Je ne sais pas pour vous, mais c’est ce genre de méthode que j’ai appris, et je les ai appliqué un certain temps avec généralement des bases de données SQL.

Cette manière de faire a ses mérites comme pouvoir poser des contraintes d’intégrité référentielles par exemple. Mais… pour autant que tout soit géré dans la même base de données.

Et pourtant, comme c’est pénible de gérer des migrations de modèles (schémas). Personne ne fait le modèle parfaitement adapté du premier coup. Vaut mieux limiter autant que possible les modifications.

Le NoSQL

J’aime beaucoup cette manière de faire. Au lieu d’avoir un modèle rigide, on a un modèle beaucoup plus simple au niveau du schéma de la base de données. Grosso modo, on veut simplement retrouver des documents en fonction d’identifiants. Les modèles de ces documents ne sont pas forcément connus par le moteur de la base de données. Les migrations se font au niveau des documents et pas au niveau du schéma de la base.

Au premier abord, on pourrait penser que c’est un pas en arrière par rapport à la manière plus traditionnelle… et pourtant.

Rester intègre

Imaginons un document A qui référence un document B. On a alors une relation de type 1-1. Mais au lieu d’avoir des tables SQL, on a simplement deux documents dans une table unique. Le document A contient un champ (une clef étrangère) avec l’id du document B.

Si j’efface le document B, je casse la relation et le moteur de la base de données ne peut pas le voir. Dans ce scénario, il y a un problème majeur. Celui-ci peut sembler surprenant pour certaines personnes mais le problème, c’est tout simplement le fait d’effacer un document. Il ne faut pas les effacer. Ce n’est pas plus compliqué que ça. Il n’est donc pas possible de casser une référence. Facile, non ?

Hein ? Ne jamais rien effacer ? Hé mec, c’est n’importe quoi…

Du calme, nous ne sommes plus en 1990. L’espace de stockage n’est pas un problème, ni les performances d’ailleurs. Il faut repenser l’effacement. Dans notre univers, on doit suivre la flèche du temps toujours dans le même sens. Ce qui veut dire qu’effacer un document revient à ne plus le présenter car finalement, dans le passé, il a existé. Ainsi on le fait simplement en lui donnant un statut. Par exemple, “trashed”. En lui donnant ce statut, on dit qu’on arrête sa flèche du temps. De cette manière on pourrait même le ressusciter un jour.

Le temps

Quand on m’a appris la modélisation de base de données, on ne m’a jamais rien appris sur le temps. Et pourtant, c’est fondamental.

Comment gérer le temps avec une modélisation classique à la Merise, UML, etc. ? Mmm… dur dur… Je ne dis pas que c’est impossible mais vous allez transpirer. Mais en NoSQL, c’est d’une très grande simplicité et voici pourquoi.

Chaque entité est un document (par exemple un JSON) avec un identifiant. Ce document, vous le stockez dans une table du type clef/valeur. Très important, la clef ne doit pas avoir de contrainte unique. Chaque mutation de l’entité doit insérer une nouvelle entrée dans cette table. Il est important que l’ordre d’insertion soit garanti. Le temps ? C’est simplement l’axe Y (les lignes). Effacer un document revient alors à insérer à la suite ce document avec le statut “trashed”.

Effacer, c’est créer une nouvel état du document.

Ce que je vous présente ici, c’est une version simplifiée de ce qu’on a mis en place avec Samuel. Chaque insertion est immuable, on peut uniquement aller de l’avant.

La suppression

Oui, il existe une situation où on peut supprimer d’anciennes entrées (d’anciens documents). Ce sont des situations très différentes car on va parler ici de maintenance et de garbage collector. Étant donné qu’on ne fait qu’insérer du neuf, on peut supprimer de l’ancien sans impacter les utilisateurs. Le scénario est du genre de ne pas garder toutes les mutations qui existent quand elles sont plus anciennes de 2 mois (par exemple). On peut imaginer garder que le dernier état. Et selon les types d’entités, on pourrait choisir des conditions différentes. On peut même tout garder pour toujours. Tout dépend des documents concernés, de l’activité par type de document, etc. Mais attention, on garde toujours au moins le dernier même si son statut est “trashed”. À moins que votre garbage collector soit capable de garantir qu’il n’y a plus aucun document qui y fait référence.

Et les SmartId dans tout ça ?

J’avais besoin de passer par une introduction pour que les SmartId prennent du sens. Nous avons donc une base de données qui contient des documents dans une table sous la forme clef/valeur. Un document de même ID peut apparaître plusieurs fois (axe temporel). Pour faire des références entre les documents, on peut :

• Ajouter une propriété dans le document A qui contient l’id du document B (1-1)
• Avoir une collection d’ID de documents B dans le document A (1-n)

C’est bien mais parfois c’est ennuyeux. On doit modifier le modèle du document A pour qu’il puisse stocker une référence au document B. Ce n’est pas toujours souhaitable et ça demande potentiellement de la migration.

Qu’est-ce que le SmartId ?

Pour avoir un SmartId minimal, il faut 2 choses. Il faut un type et il faut un texte ou numéro unique par type. Imaginons que le document est un message. Nous avons le type “message”. Nous pouvons utiliser un UUID pour la partie unique. Par exemple :

• message@8b05f82c9294483ab4ba5a7961f2e923

Mais on peut aussi utiliser ce qui nous arrange :

• message@99000
• message@main

Utiliser un UUID donne une garantie d’unicité. Utiliser un mot comme “main” permet de différencier une des entités. Ce qui veut dire que vous pouvez mélanger différentes sortes d’identifiants tant que vous garantissez qu’il ne peut pas y avoir de conflit. En ayant “main” et des UUID, il est garanti qu’il n’y aura jamais un UUID qui sera par hasard sous la forme de “main”.

Pourquoi le type dans l’id ?

En ayant le type dans l’id, il est possible de stocker différents types de documents dans la même base de données et sans conflits. Nous pourrions avoir message@main ainsi que user@main dans la même base. On pourrait éviter le type en ayant une base “message” et une base “user”. Ou pas, parce que les SmartId sont bien plus que ça. Chez nous, on fait les deux. Ce que je veux dire, c’est qu’on a des bases de données par domaine et plusieurs types par domaine. Ce que j’ai présenté avant, ce sont les SmartId minimaux : type@unique. Mais les SmartId sont composables et voici comment et pourquoi.

type1@type2@unique

Mais qu’est-ce que c’est que ça ?

journal@workitem@unique

Exemple 1

Voici un exemple très courant dans notre système. Nous créons un service “journal” qui gère une sorte de journal pour le service “workitem”.

Les SmartId ne sont pas utilisés que pour les entités mais aussi pour les services qui manipulent des entités. workitem@unique est un service pour modifier des entités. Ce workitem va créer un service “journal”. Le service “journal” hérite de l’identifiant du workitem. Ce journal ne peut exister que pour cette instance du workitem. Ici vous pouvez alors deviner une relation forte (uniquement avec l’ID) entre le service journal et le service workitem.

Exemple 2

Un autre exemple avec les entités. Imaginons que nous avons un type d’entité “message” qui représente un message générique dans le système. Il est possible que ce message existe aussi sous la forme d’un email, mais pas toujours. En modélisant, on pourrait se dire : « suffit de mettre une référence du message dans l’entité email ». On crée une relation avec le modèle du document. Mais parfois ce n’est pas approprié de modifier le modèle. Simplement qu’on ne souhaite pas polluer le modèle et encore moins le migrer. Pour cela, on peut compter sur les SmartId. Quand un email est créé à partir d’un message, on peut alors faire :

• message@123456789
• email@message@123456789

Les SmartId nous permettent de créer une dépendance 1-1 sans toucher aux modèles.

Exemple 3

Nous avons utilisé ce principe pour les tags sur les entités. Ici, je vais vous donner un exemple en production. Pour moi (et pas que moi), il est exclu de toucher aux modèles des entités pour les polluer avec des tags.

Mais on nous a demandé d’intégrer les tags bien après que nos modèles soient réalisés. Voici comment les SmartId ont résolu la problématique. Nous avons des entités de type “tag”. Par exemple :

• tag@wishes
• tag@prospect
• tag@supplier

Un tag a de la couleur, un nom, une description, etc.

Nous avons des entités de type “entityTags”. Par exemple :

• entityTags@contact@unique

Le contact à comme SmartId contact@unique. Ici on créer simplement un id de type “entityTags” qui utilise l’id du contact comme identifiant unique. C’est exactement comme avec l’exemple du message et de l’email présenté précédemment.

“entityTags” contient la liste des liens sur les tags associés à l’entité contact@unique. Cette entité “entityTags” sert de table de relations.

Cette entité “entityTags” n’est pas indispensable. Mais elle est pratique pour faciliter l’édition des tags de l’entité avec notre framework UI.

“entityTags” ne contient pas une collection de tag@ mais une collection de tagLink@ (oui encore un type). Un “tagLink” se présente ainsi :

• tagLink@contact@unique@tag@supplier

Ce “tagLink” peut contenir des données utilisateur qui sont par exemple introduites au moment de l’application du tag sur le contact. C’est optionnel et très pratique.

Il serait possible de se passer des “entityTags” car les relations entre l’entité et les tags peuvent être exprimées uniquement avec les “tagLink”. Le “tagLink” contient tout ce qui est nécessaire dans son SmartId. On y trouve l’entité sur laquelle le “tagLink” est lié contact@unique, on y trouve également le tag associé tag@supplier. Avec une requête dans la base de donnée il serait facile de retrouver tous les tags associés à une entité en particulier uniquement en se basant sur les ID. Chez nous on utilise l’“entityTags” car notre framework UI sait bien travailler avec des collections qui existent réellement dans une entité. Avec une requête sur une liste d’ID, la UI nécessiterait quelques adaptations supplémentaires.

Avec ce système basé sur les SmartId, il est alors possible d’assigner des tags à n’importe quelle entité du système sans toucher au moindre modèle et tout en pouvant assigner des données avec chaque tag posé. Finalement le schéma se construit avec les SmartId car l’entité “contact” n’a jamais de référence sur entityTags@contact@unique dans son modèle.

Les liens avec l’extérieur

Je souhaite encore vous présenter un cas d’utilisation très pratique des SmartId. Nous avons des systèmes où nous devons importer régulièrement des données externes en plus de gérer nos propres entités. Imaginons des clients (par exemple). Le système crée des clients sous la forme customer@uuid. Le système externe crée des clients avec des nombres auto-incrémentés. Client 1001, 1002, 1005, 1011, … Un système traditionnel… Quand nous importons depuis ce système, nous pouvons utiliser les SmartId ainsi (par exemple) :

• customer@1001-extern

Nous n’avons pas de risque de conflit avec nos propres ID et il est très facile d’effectuer une mise à jour. L’importateur des externes va simplement chercher l’entité customer@XXXX-extern existante (ou la créer au besoin). Sans les SmartId, tout devient plus complexe car certainement qu’on devrait conserver l’id extern dans le modèle de l’entité customer. En plus, la recherche de l’entité à synchroniser à l’import se complexifie. Beurk… Merci les SmartId.

Si je ne vous ai pas convaincu ce n’est pas très grave car ce n’est pas mon objectif, mais tant mieux si ça peut vous faire réfléchir. En ce qui me concerne, depuis lors, je n’ai plus aucune envie de faire de la modélisation à la façon de grand-papa.