Dans un précédent article [1], j’avais présenté le projet AlaSQL au travers de techniques SQL présentant un niveau de difficulté allant de facile à moyennement complexe. Parmi les techniques les plus complexes, nous avions vu comment manipuler des données liées à des dates d’effet. Dans ce nouvel épisode, j’ai voulu tester AlaSQL sur un panel de techniques un peu plus large, dans le but de déterminer jusqu’à quel point cet outil est en mesure de nous accompagner dans le développement de règles métier. On va voir que malgré quelques limites, AlaSQL peut couvrir de nombreux besoins avec efficacité, et même élégance (au moins, dans certains cas).
Dans GLMF n° 250 [1], je vous avais présenté le projet AlaSQL. Pour les personnes qui n’auraient pas lu cet article, je précise que AlaSQL est un projet open-source implémentant un moteur SQL écrit en JavaScript. Ce projet fonctionne aussi bien dans les navigateurs que dans Node.js. Il est capable de traiter des requêtes SQL complexes, combinant plusieurs niveaux de sous-requêtes. Grâce à cela, on peut par exemple sélectionner des données soumises à dates d’effet (notamment des tarifs), c’est ce que j’avais montré dans mon précédent article. Je rappelle que AlaSQL supporte les CTE (Common Table Expression), ce qui permet d’écrire des sous-requêtes plus lisibles, et donc plus maintenables que le principe des sous-requêtes imbriquées sur plusieurs niveaux (j’évoquais ce problème dans l’article précédent, alors je n’y reviens pas ici).
Ce nouvel article se compose de trois parties :
- une première partie dans laquelle je vais...
- Accédez à tous les contenus de Connect en illimité
- Découvrez chaque semaine un nouvel article premium
- Consultez les nouveaux articles en avant-première
