13 raisons pour abandonner SQL

Malgré sa popularité et son succès, SQL est un paradoxe. Peu convivial et verbeux, ce langage de programmation (littéralement langage de requête structuré) constitue cependant pour le développeur lambda le moyen le plus simple pour manipuler et extraire des données. Il peut être très rapide lorsqu'une requête est correctement rédigée mais extrêmement lent le cas échéant. Il existe depuis des décennies, mais regorge de fonctionnalités ajoutées et intégrées au fil du temps. Ces paradoxes n'ont pas d'importance, car le marché a parlé : SQL est le premier choix de nombreux utilisateurs même s'il existe des alternatives plus récentes et sans doute plus performantes.

Partout, les programmeurs travaillant aussi bien pour de petits sites web que de très grandes entreprises, connaissent SQL. Ils s'appuient sur lui pour organiser toutes leurs données. Le modèle tabulaire de SQL est si dominant que de nombreux projets non SQL finissent par ajouter une interface de ce langage parce que les utilisateurs l'exigent. Même NoSQL - pourtant plus évolutif, flexible et performant pour gérer des données non structurées - n’est jamais parvenu à le supplanter.

Les limites de SQL ne suffisent peut-être pas à le reléguer aux oubliettes de l'Histoire. Les développeurs ne se révolteront peut-être jamais et ne migreront jamais toutes leurs données hors de SQL. Toutefois ses problèmes sont suffisamment réels pour générer du stress, cumuler des retards et même nécessiter de refondre certains projets. Voici treize raisons qui pousseraient à abandonner SQL, même si cela sera probablement difficile.

1. Des tables qui ne sont pas évolutives

Le modèle relationnel adore les tables, alors il faut continuer tout simplement à les créer. Si cela fonctionne bien pour les bases de données de petite ou moyenne taille, à plus grande échelle les limites sont atteintes. Certains tentent de résoudre le problème en intégrant par exemple le partitionnement dans une base de données open source plus ancienne. L'ajout de couches parait comme un bon moyen pour simplifier la gestion des données et apporter une évolutivité infinie mais peut cacher des pièges. Les instructions SELECT ou JOIN peuvent nécessiter un temps de traitement très variable en fonction de la quantité de données stockées dans les partitions (shards). Le partitionnement oblige également l'administrateur de bases de données à envisager la possibilité que les données soient stockées ailleurs sur un autre système pouvant entraîner des difficultés. Un administrateur inexpérimenté commençant à effectuer une recherche dans une table peut ainsi être dérouté s'il ne se rend pas compte que les données sont stockées à différents endroits.

2. SQL n'est pas natif pour JSON ou XML

Le langage SQL est peut-être intemporel mais il n'est pas particulièrement compatible avec les formats d'échange de données plus récents tels que JSON, YAML et XML. Ceux-ci prennent en charge une structure plus hiérarchique et plus flexible que SQL. Les bases de données SQL restent prisonnières du modèle relationnel et d'un nombre incalculable de tables. Des moyens sont utilisés pour masquer cette critique courante. Certaines bases de données SQL peuvent encoder et décoder des formats de données plus modernes comme JSON, XML, GraphQL ou YAML en tant que fonctionnalités natives. Mais en regardant de près, on voit que les données sont généralement stockées et indexées à l'aide du même ancien modèle tabulaire. Le formatage JSON n'est en fait qu'une façade qui peut faciliter la vie des développeurs mais peut aussi masquer les coûts de conversion. Combien de temps faut-il pour convertir les données vers et à partir de ces formats ? Ne serait-il pas plus simple de stocker les données d'une manière plus moderne ? Certains programmeurs de bases de données ingénieux continuent d'expérimenter, mais le plus étrange c'est qu'ils finissent souvent par ajouter une sorte d'analyseur SQL.

3. Le triage, une activité très chronophage

Les bases de données peuvent stocker des données dans des tables mais les développeurs écrivent du code pour traiter des objets. Il semble qu'une grande partie du travail de conception d'applications basées sur les données consiste à trouver le meilleur moyen d'extraire les données d'une base et de les transformer en objets que la logique métier peut utiliser. Avant ensuite de fusionner en upsert SQL leurs champs de données. N'y a-t-il pas un moyen de laisser les données dans un format prêt à l'emploi pour éviter tout ce travail de triage (marshalling) ?

4. SQL ne fonctionne pas en temps réel

La base de données SQL a été conçue à l’origine pour les traitements analytiques par lots contrairement à d’autres modèles de données en continu plus récents, avec de longs pipelines de traitement. Ce type de base a été conçue il y a plusieurs décennies, à une époque où le modèle l'imaginait en tant qu’élément autonome pour répondre à des requêtes, parfois rapidement, parfois non. C'est ainsi que fonctionne le traitement par lots. Mais certaines des applications les plus récentes exigent de meilleures performances en temps réel, non seulement pour des raisons de commodité, mais aussi parce que l'application l'exige. Une situation où SQL montre ses limites.

5. La commande JOIN est un casse-tête

La puissance des bases de données relationnelles provient du fractionnement des données en tables plus petites et plus concises. Mais c'est ensuite que les problèmes commencent. Le ré-assemblage des données à la volée à l'aide de la commande JOIN est souvent la partie la plus coûteuse en termes de calcul, car la base de données doit jongler avec toutes les données. Les problèmes commencent lorsque les données dépassent la capacité de la mémoire vive. Les jointures JOIN peuvent être extrêmement déroutantes pour quiconque apprend le langage SQL. Comprendre la différence entre ces requêtes internes et externes n'est déjà pas facile mais trouver la meilleure façon d’en connecter plusieurs est encore plus compliqué.

6. Les colonnes sont un gaspillage d'espace

L'une des grandes idées du NoSQL était de libérer les utilisateurs des contraintes liées aux colonnes. Si quelqu'un souhaitait ajouter une nouvelle valeur à une entrée, il pouvait choisir le tag ou le nom de son choix. Il n'était pas nécessaire de mettre à jour le schéma pour ajouter une nouvelle colonne. Les défenseurs du SQL ne voient que le chaos dans ce modèle. Ils apprécient l'ordre qui règne dans les tables et ne veulent pas que les développeurs ajoutent de nouveaux champs à la volée. Ils ont raison, mais l'ajout de nouvelles colonnes peut être coûteux et prendre beaucoup de temps, en particulier dans les grandes tables. Placer les nouvelles données dans des colonnes séparées et les faire correspondre avec des jointures JOIN prend encore plus de temps et s'avère toujours plus complexe.

7. L'optimisation à ses limites

Les sociétés spécialisées dans les bases de données et les chercheurs ont consacré beaucoup de temps à développer de bons optimiseurs qui décomposent une requête et trouvent le meilleur moyen d'ordonner ses opérations. Les gains peuvent être importants, mais les capacités d'un optimiseur ont leurs limites. Si l'administrateur de la base de données soumet une requête complexe, l'optimiseur ne peut pas tout faire. Certains administrateurs ne s'en rendent compte que lorsque l'application commence à évoluer. Les optimisations initiales suffisent pour traiter les ensembles de données de test pendant le développement. Mais au moment crucial, l'optimiseur se heurte à un mur. Il ne peut tirer qu'un maximum limité d'une requête.

8. La dénormalisation traite les tables comme des déchets

Les développeurs se retrouvent souvent pris entre les utilisateurs qui veulent des performances plus rapides et les comptables qui ne veulent pas payer pour le matériel. Une solution courante consiste à dénormaliser les tables afin d'éviter les jointures JOIN complexes ou tout croisement de tables. Ce n'est pas une mauvaise solution technique, et elle l'emporte souvent car l'espace disque est devenu moins cher que la puissance de traitement. Mais la dénormalisation - technique utilisée en SQL pour améliorer les performances des requêtes en réduisant le nombre de jointures entre les tables - met également de côté les aspects les plus pratiques du SQL et de la théorie des bases de données relationnelles. Toute la puissance sophistiquée de la base de données est ainsi pratiquement anéantie lorsque celle-ci devient un long fichier CSV.

9. Des fonctions additionnelles dangereuses

Depuis des années, les développeurs ajoutent des fonctionnalités supplémentaires à SQL, dont certaines sont très ingénieuses. Il est difficile de se plaindre de celles intéressantes que l'utilisateur n'est pas obligé d'utiliser. D'un autre côté, elles ont souvent ajoutées à la va-vite, ce qui peut entraîner des problèmes de performances. Certains développeurs recommandent d'être particulièrement prudent avec les sous-requêtes, car elles ralentissent tout le processus. D'autres affirment que la sélection de sous-ensembles tels que les expressions de table communes, les vues ou les fenêtres complique excessivement le code. Le développeur peut le lire, mais tous les autres ont du mal à comprendre toutes les couches et générations de SQL. Certaines de ces idées géniales nuisent à ce qui fonctionne déjà. Les fonctions de fenêtre (ROW_NUMBER , RANK, et DENSE_RANK) ont été conçues pour accélérer l'analyse des données de base en accélérant le calcul des résultats tels que les moyennes. Mais de nombreux utilisateurs SQL préfèrent utiliser une fonctionnalité ajoutée. Dans la plupart des cas, ils l’essaient et ne remarquent que quelque chose ne va pas lorsque leur machine ralentit considérablement. Ils ont alors besoin d'un administrateur de base de données expérimenté pour leur expliquer ce qui s'est passé et comment y remédier.

10. La syntaxe SQL trop fragile (ou pas)

Dans un passé lointain, lorsque le langage SQL a vu le jour, seuls les humains écrivaient du code SQL. Aujourd'hui, de nombreux systèmes assemblent automatiquement les requêtes. Cela donne aux utilisateurs naïfs ou malveillants trop de pouvoir pour commettre des actes répréhensibles. Les administrateurs de bases de données apprennent rapidement à éviter les mots réservés, mais cela n'aide pas l'utilisateur occasionnel qui pourrait simplement vouloir utiliser la commande SELECT avec une clause GROUP pour agréger une colonne. Il existe également de merveilleuses solutions standard pour éviter d’utiliser des mots réservés tels que “SELECT”, “INSERT” et “UPDATE”. MySQL utilise des guillemets inversés. PostgreSQL utilise des guillemets doubles. Assurez-vous simplement d'utiliser les bons pour votre version de SQL. Pour aggraver les choses, des attaquants ingénieux peuvent cibler ce point faible en injectant des commandes SQL dans les requêtes. Au lieu de simplement taper leur nom dans un champ, l'attaquant saisit ; DROP TABLE users; DROP TABLE products; DROP TABLE orders;--. L'analyseur SQL se fait alors un plaisir d'exécuter ce qu'on lui demande... Après tout, il a été écrit à une époque où seuls les humains émettaient des requêtes.

11. Toutes les données ne rentrent pas dans une table

Une quantité importante de données s'intègre parfaitement dans des tables, mais toutes ne s’intègrent pas aussi bien. Par exemple, les réseaux sociaux, les données hiérarchiques et de nombreux phénomènes scientifiques sont modélisés à l'aide de graphiques. Ceux-ci peuvent être stockés dans des tables, mais toute opération autre que la requête la plus simple devient complexe. Et puis il y a les données spatiales en deux ou trois dimensions. Au moins, les données chronologiques n'ont qu'un seul axe principal. D'autres données existent en deux, trois ou peut-être même plusieurs dimensions. Les tables, cependant, n'ont qu'un seul axe pour les lignes et un axe secondaire pour les différentes colonnes. Cela signifie qu'il est possible de stocker des données bidimensionnelles telles que la latitude et la longitude, mais que les calculs multidimensionnels tels que la distance ne sont pas faciles à réaliser. De nouvelles extensions géographiques peuvent pallier ce problème, mais le paradigme reste limitatif.

12. SQL n'est pas vraiment standard

SQL est peut-être une norme ANSI/ISO (ce langage a été créé en 1974 et normalisé en 1986), mais cela ne signifie pas pour autant que vous pouvez simplement le transférer d'une implémentation prenant en charge cette norme à une autre. Vous devez penser à une autre signification du mot « norme ». Les administrateurs de bases de données connaissent très bien les nombreuses différences syntaxiques. MySQL utilise « CURDATE() », Oracle utilise « SYSDATE » et PostgreSQL utilise « CURRENT_DATE ». SQL Server vous permet de concaténer des chaînes à l'aide de l'opérateur « + ». D'autres utilisent deux barres verticales (« || »). Les dizaines d'incompatibilités syntaxiques ne sont qu'un début. Il existe des différences philosophiques majeures entre les implémentations des procédures stockées, des déclencheurs et des fonctions prises en charge. Même les types de données fondamentaux présentent des nuances en termes de précision et de plage.

13. De meilleures options à considérer

Les équipes informatiques doivent souvent se contenter de ce qui existe déjà. La meilleure raison pour laquelle SQL doit disparaître est qu'il existe de meilleures alternatives, plus concises, plus flexibles et plus lisibles. GraphQL, par exemple, est souvent utilisé dans les applications web, où il sert à demander les combinaisons de données appropriées à l'aide d'un modèle simple. Les données hiérarchiques sont naturellement prises en charge. Il existe déjà plusieurs bonnes options pour effectuer des recherches dans les bases de données NoSQL. La plupart des bases de données clé-valeur recherchent simplement les nœuds correspondants. D’autres comme MongoDB (MQL) imitent la norme JSON très répandue. Les développeurs qui utilisent certaines solutions centrées sur les documents, comme SOLR ou Elasticsearch, peuvent utiliser des fonctions de similarité complexes et toutes permettent de prendre en charge des requêtes à la fois plus puissantes et plus faciles à lire et à créer pour les humains. Elles offrent des possibilités de stockage des données qui ne se limitent pas à des tables remplies de lignes et de colonnes.