Si vous avez travaillé avec un logiciel qui communique avec une base de données, il y a de fortes chances que vous soyez déjà tombé sur une grosse requête SQL. Lentement, vos yeux se fixent sur le logiciel alors que vous essayez de raisonner à travers les nombreuses connexions et sous-requêtes, en essayant de comprendre si cette requête est la source du bug.
Vous hésitez entre les différentes options. Devriez-vous rechercher le créateur original de la requête, ou la réorganiser vous-même pour avoir une chance de comprendre ses complexités cachées ?
Pour être honnête, il y a beaucoup de code non-SQL qui peuvent provoquer une réaction similaire. Cependant, je me suis rendu compte que l’intégration de grosses requêtes SQL dans le code peut limiter une base de code en constante évolution.
Le problème d’une grosse requête SQL
Les requêtes SQL sont idéales pour poser des questions sur un ensemble de données. Elles sont performantes, familières à tous les projets et, dans l’ensemble, très puissantes. Honnêtement, l’une de mes parties préférées du développement de logiciels est l’écriture de grosse requêtes assez complexes.
Cependant, j’ai remarqué une tendance dans mes projets : Les requêtes SQL relient dangereusement les logiciels à leur niveau de persistance. Il est évident que nous avons besoin des requêtes SQL pour récupérer des données à partir de nos sources de données, mais il est facile pour les développeurs d’en abuser.
Je me suis retrouvé à intégrer des règles business clés dans les requêtes, en plus de leur responsabilité normale de récupération de données. Dans une grosse requête, la logique business peut être obscurcie par les nombreuses parties mobiles d’une requête. Les requêtes doivent définir les relations entre différents éléments de données, joindre ces tableaux, regrouper les lignes de résultats, ordonner l’ensemble des résultats, etc.
Alors qu’un développeur pourrait écrire une requête très efficace pour extraire des données et appliquer des règles de gestion, cette approche n’est pas viable pour un logiciel en évolution. Au fur et à mesure que la compréhension du domaine business s’accroît, le modèle de données évolue pour tenir compte des nouvelles découvertes. Cependant, toute modification apportée au schéma de la base de données implique généralement de retravailler, ou de réorganiser complètement une requête. Parfois, j’ai même choisi de ne pas changer le modèle de données par crainte de recréer un grand nombre de requêtes SQL dans un système délicat.
Alternatives à une grosse requête SQL
Pour éviter la difficulté d’avoir une grosse requête SQL intégrées dans le code de production, j’ai trouvé deux alternatives :
- Utiliser beaucoup de petites requêtes.
- Utiliser des constructeurs de requêtes.
La première alternative est simple. Au lieu d’essayer d’atteindre la base de données avec une seule requête qui peut tout saisir en même temps, envisagez de décomposer le processus en plus petits morceaux. Écrivez quelques requêtes pour saisir des sections de données, en effectuant un traitement quelconque en mémoire au lieu de fonctions d’agrégation. J’ai trouvé cette approche utile pour comprendre pleinement un problème sans avoir à passer à la solution la plus performante.
Il est également utile de considérer les compromis en matière d’efficacité lors de l’utilisation de petites requêtes. Les petites requêtes ont tendance à avoir moins de responsabilité, elles peuvent donc être appliquées dans un plus grand nombre de situations. Comme pour le principe de la responsabilité unique des fonctions, les requêtes comportant un petit ensemble de responsabilités ont plus de chances d’être vraiment bonnes dans leur travail, correctes et vérifiables.
Je préfère la deuxième solution, qui consiste à utiliser des constructeurs de requêtes. J’ai eu beaucoup de succès en décomposant de grosses requêtes complexes en petites fonctions qui décrivent chaque aspect d’une requête. Cela permet d’obtenir un ensemble de requêtes multiples avec des concepts partagés. Si vous travaillez sur Node.js, je vous recommande vivement de consulter Knex.js pour la construction des requêtes.
Dernières réflexions sur les grosses requêtes
Une grosse requête a sa place dans le développement de logiciels, certains problèmes doivent être résolus avec les outils les plus performants. Cependant, je trouve qu’il vaut la peine de décomposer les grosses requêtes qui sont assez complexes en plus petits morceaux. Des requêtes plus petites permettent une plus grande flexibilité dans l’évolution des logiciels, ce qui est souvent aussi souhaitable que la performance (et parfois plus).