Du JSON dans MySQL
Introduit dans la version 5.7.8, le support natif du type de donnée JSON permet de stocker n’importe quelle structure JSON dans un champ unique. Bien qu’il était déjà possible de le faire via un champ de type TEXT par exemple, l’utilisation d’un type dédié apporte plusieurs avantages :
- la validation du format de données (limitée au respect du standard) pour éviter les données malformées,
- un stockage optimisé sous forme binaire évitant de parser le contenu à chaque requête et permettant d’accéder rapidement aux sous-objets,
- et surtout la possibilité de filtrer / modifier directement les données via de simples requêtes SQL.
Testons avec un exemple simple :
On a ici
- créé une table avec un champ document de type JSON,
- inséré 2 lignes,
- filtré en utilisant le champ key1 du champ JSON,
- modifié le champ key1 d’un document.
On l’a vu, le type JSON s’utilise assez facilement, via des fonctions dédiées. Pour autant, il reste certaines contraintes qui limitent son utilisation potentielle :
- il n’est pas possible de définir une contrainte d’intégrité entre le contenu d’un champ JSON et une table (clé étrangère)
- il n’est pas possible d’indexer les champs au sein d’un champ JSON, ce qui peut avoir un sérieux impact sur les performances
Ce deuxième point peut être nuancé par l’utilisation d’une colonne générée automatiquement à partir d’une clé spécifique dans le JSON, permettant de filtrer sur cette clé (mais pas de modifier la valeur).
Le type JSON n’est donc pas utilisable partout mais il reste utile dans certaines situations telles que :
- le stockage d’une liste d’éléments simples sur un objet (sans avoir recours à une table dédiée et une jointure),
- le stockage d’objets polymorphes,
- le stockage de structures complexes dont on n’a que faire au niveau du SQL.
En conclusion, l’utilisation du type JSON est un outil supplémentaire à notre disposition pour modéliser nos données, à utiliser avec parcimonie. L’idée ici n’est pas de révolutionner l’utilisation de MySQL, ni de concurrencer un MongoDB, mais de fournir une modélisation alternative bien pratique sur des cas précis.
Un frein à son adoption est peut-être le manque de support dans les outils / frameworks existants. A titre d’exemple, il n’y a pas de support officiel pour Hibernate, même si des solutions existent (custom type, bibliothèque hibernate-types).
Merci pour votre lecture 👩💻
Vous avez aimé cet article ? Cliquez sur 👏 pour que d’autres lecteurs puissent le trouver !
