Le SQL est en train de sortir de la vie du travailleur Web
Est-ce une mauvaise chose? Non!
Pourquoi?
Le SQL est un langage non sémantique et purement technique. Regarder des requêtes SQL ne nous apprend absolument rien sur le portrait général de l’application. C’est pourquoi tout bon développeur s’efforce de cacher les requêtes SQL au plus profond de son application afin que personne ne tombe dessus par hasard.
Si j’écris : Student.find_best, je viens d’écrire une ligne qui veut dire quelque chose. Je veux aller chercher les meilleurs étudiants, point. À l’inverse, si j’écris :
Il n’y a rien de sémantique là-dedans. Je me suis simplement appliqué sur le côté technique de la chose, le côté qui ne nous intéresse pas. Pourquoi? Parce que nous développons des applications Web et non des requêtes SQL. Hein? Qu’entend-je? Vous me dites que le SQL fait partie de la tâche du travailleur Web? Alors diriez-vous également que le menuisier devrait faire ses propres clous avant de bâtir une maison? Tout pêcheur devrait construire sa canne à pêche avant d’aller pêcher?
Il faut avoir une vue d’ensemble pour faire une bonne application Web. Si on s’enfonce dans des technicalités juste pour se prouver qu’on est bon et qu’on est capable de tout faire, on manque le bateau. Le point n’est pas de se demander si on est capable de faire une requête SQL (tout le monde s’en fout de ça) mais plutôt de se demander si cela ne détourne pas notre attention sur ce qui est vraiment important : Développer une application Web. Cela inclus de se concentrer sur les besoins que notre application tente de combler, sur l’accessibilité, la sécurité, la performance, le design, la validité du code (X)HTML/CSS, etc. Sans oublier qu’il faut faire les efforts nécessaires pour être au goût du jour et incorporer (intelligement et si nécessaire) du AJAX, des tags, un wiki ou tout aute truc du genre. Si on peut enlever le SQL de notre chemin une bonne fois pour toute, on pourrait avoir plus de temps pour les vraies affaires.
J’ai travaillé en ASP.NET (1.1) pendant 4 ans. Vers la fin, je vous jure que j’en avais plus qu’assez de me créer des couches d’accès aux données (Data Access Layers) et d’y centraliser mes requêtes SQL. A chaque fois j’avais l’impression d’abandonner mon projet pour aller faire de la “job de bras” avec SQL. Quand je revenais à mon application, j’avais toujours cette phrase qui résonnait dans ma tête : “On perd notre temps en faisant ça à chaque fois”.
Heureusement, les nouveaux frameworks web avancent dans cette direction et peu à peu réduisent la nécessité d’écrire du SQL manuellement. Avec des frameworks tels cakePHP, Django et Rails, le code SQL est généré dynamiquement dans une couche (layer) réservée à cet effet. De notre côté, on n’a qu’à utiliser des objets pour manipuler les différents composants de notre application. On peut enfin se concentrer sur ce qui est important et arrêter de perdre notre temps dans du code SQL laid et difficile à maintenir.
Tu vas en choquer plus d’un avec cet article. J’ai déjà tenu des propos beaucoup moins durs envers le SQL et j’ai eu l’impression de passer pour un incompétent. Comme si c’était impossible de produire une application rapide puisque le SQL ne m’intéressait pas. Pour couper la poire en deux, je dirais que quand on programme il faut garder un bon équilibre quant à nos préoccupations. Pas trop penser aux éléments techniques et pas juste penser à l’application et programmer n’importe comment. J’ai le sentiment que le SQL est trop technique, c’est pas irresponsable de vouloir avoir à faire à des outils de plus haut niveau pour brasser la base de données. Faut simplement être capable, en cas de mauvaises performances par exemple, de pouvoir contrôler les requêtes. À ce que je sache, tant qu’on est capable d’en faire nous même, les frameworks que tu nommes permettent de faire nos requêtes à la main. Le meilleur des deux mondes bref.
Ouais. J’ai décidé de prendre une avenue à sens unique. Les articles “milieu” ont tendance à moins lever.
En effet, il arrivera toujours des moments où on aura à écrire du SQL manuellement. Je ne veux surtout pas suggérer l’arrêt de l’enseignement du SQL dans les écoles. C’est un langage qui demeure très important à connaître.
Mon point est que je crois qu’il y a encore trop de gens qui écrivent et ré-écrivent les mêmes requêtes SQL dans leurs différents projets. C’est toujours à recommencer. Les noms de tables, les champs et les liaisons changent, mais le reste c’est du copier-coller. Un bon pourcentage du SQL dans une application web typique est composé de requêtes SQL simples et de base. Il n’y a pas grand chose à optimiser là…
Ça ne sert plus à rien d’écrire ce genre de requêtes encore et encore. Perte de temps…
Comme j’ai déjà dit… eee… je ne me rappelle plus où, le framework utilisé afin d’esquiver le SQL ne doit jamais nous empêcher d’en écrire. Un objet “db_request” ou autre devrait toujours avoir une propriété genre “SQLString” pour nous permettre d’écrire soi-même la requête. Le cas échéant, le framework perdera bien des adeptes de l’optimisation SQL.
Cette optimisation SQL devient de moins en moins importante avec le progrès technologique affectant la vitesse de nos processeurs, mais elle reste toujours capitale lors de requêtes impliquant des tables contenant des millions de lignes, parce que, vous savez les requêtes générées contenant des right-join, c’est pas ce qu’on peut appeler de l’efficacité!
C’est certain que les performances des ordinateurs est plus grande sauf que pour des sites avec un achalandage monstre, c’est pas évident. J’aurais tendance à dire que c’est beaucoup plus important d’optimiser quand il y a plein d’usager que quand les tables ont 10 000 enregistrements.
Juste une petite parenthèse…