Le SQL est un langage standardisé (et d'ailleurs, PostgreSQL est un SGDB qui respecte le standard, presque le seul, hors fonctionnalités qui vont au delà du standard) qui a plus de 40 ans maintenant.
Ça s'apprend, et c'est pas compliqué en vrai. J'en fais depuis des années certes, donc c'est difficile de me mettre dans la peau de quelqu'un qui apprend de zéro, mais je l'ai appris à un moment ou un autre. Le seul changement de paradigme un peu perturbant, je pense, c'est de raisonner de façon ensembliste (bien que le SQL ne soit pas réellement une transposition de la théorie des ensembles, il s'en inspire). Toute personne qui travaille sur un langage qui gère correctement les collections et a un système de typage complet y trouvera beaucoup de choses familières. Enfin, pour des requêtes simples, et même certaines plus complexes, il n'y a définitivement pas besoin d'être mathématicien, ni même de connaître quoi que ce soit à propos de la théorie des ensembles.
En plus, c'est vraiment cool comme langage, parce que c'est spécifié comme étant un langage déclaratif: tu dis ce que tu veux comme résultat, et c'est au serveur de choisir comment l'interpréter, et de choisir la façon optimale pour obtenir le résultat que lui a demandé.
Donc en tant que développeur, le langage t'ôte la responsabilité de devoir penser performance à la place du serveur, ce qui le rend bien plus accessible que la majeure partie de langages qu'on manipule tous les jours, qui vous nous exposer des détails techniques complexes pour permettre de contourner les faiblesses de ton processeur ou te forcer à gérer ta mémoire par toi même. Le SQL s'affranchit complètement de toutes ces contraintes qui polluent la sémantique, et te permet de réfléchir uniquement à tes données. Il te fourni une langue pour exprimer simplement des transformations de collections de données. C'est même bien plus expressif et lisible que les libraries réactive-fonctionnelles très à la mode en ce moment.
PostgreSQL est réputé pour avoir le meilleur moteur d'optimisation de requête SQL au monde (à tel point qu'il est aussi utilisé par d'autres outils) et pour avoir testé et écrit des choses vraiment compliquées avec, mis à part de très rare cas (vraiment très rare) avec les versions récentes de PostgreSQL plus tu écris le SQL simplement et naïvement, et mieux ça se passe.
Des langages qui ont essayé de substituer au SQL, ça existe, mais aucun ne fait consensus, et à mon avis ce n'est pas pour rien: aucun de ceux que j'ai pu rencontrer ne permettait réellement d'être à la fois généraliste et d'abstraire des fonctionnalités avancées du SQL dans quelque chose de plus simple.
Je pense honnêtement, au vu de ce que ça permet de faire, que de concevoir un langage plus simple que le SQL pour le remplacer semble impossible, quant bien même il pourrait sûrement être amélioré (je pense notamment à la syntaxe horrible pour les accès au json). Il y a des cas où c'est possible et ça marche, mais c'est presque systématiquement des langage qui sont en fait des DSL (Domain Specific Language), conçus pour répondre à des problématiques métier, et qui par conséquent ne peuvent être utilisé en dehors.
Après, rien n'empêche d'imaginer un jour écrire un SQL-v2, qui soit une nouvelle langue plus moderne, mais je pense que sa complexité sera au moins équivalente au SQL lui même.
[^] # Re: Scylla/MongoDB
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Cassandra 4 qui la testent, un qui l'Hécube. Évalué à 8. Dernière modification le 06 août 2021 à 10:03.
Le SQL est un langage standardisé (et d'ailleurs, PostgreSQL est un SGDB qui respecte le standard, presque le seul, hors fonctionnalités qui vont au delà du standard) qui a plus de 40 ans maintenant.
Ça s'apprend, et c'est pas compliqué en vrai. J'en fais depuis des années certes, donc c'est difficile de me mettre dans la peau de quelqu'un qui apprend de zéro, mais je l'ai appris à un moment ou un autre. Le seul changement de paradigme un peu perturbant, je pense, c'est de raisonner de façon ensembliste (bien que le SQL ne soit pas réellement une transposition de la théorie des ensembles, il s'en inspire). Toute personne qui travaille sur un langage qui gère correctement les collections et a un système de typage complet y trouvera beaucoup de choses familières. Enfin, pour des requêtes simples, et même certaines plus complexes, il n'y a définitivement pas besoin d'être mathématicien, ni même de connaître quoi que ce soit à propos de la théorie des ensembles.
En plus, c'est vraiment cool comme langage, parce que c'est spécifié comme étant un langage déclaratif: tu dis ce que tu veux comme résultat, et c'est au serveur de choisir comment l'interpréter, et de choisir la façon optimale pour obtenir le résultat que lui a demandé.
Donc en tant que développeur, le langage t'ôte la responsabilité de devoir penser performance à la place du serveur, ce qui le rend bien plus accessible que la majeure partie de langages qu'on manipule tous les jours, qui vous nous exposer des détails techniques complexes pour permettre de contourner les faiblesses de ton processeur ou te forcer à gérer ta mémoire par toi même. Le SQL s'affranchit complètement de toutes ces contraintes qui polluent la sémantique, et te permet de réfléchir uniquement à tes données. Il te fourni une langue pour exprimer simplement des transformations de collections de données. C'est même bien plus expressif et lisible que les libraries réactive-fonctionnelles très à la mode en ce moment.
PostgreSQL est réputé pour avoir le meilleur moteur d'optimisation de requête SQL au monde (à tel point qu'il est aussi utilisé par d'autres outils) et pour avoir testé et écrit des choses vraiment compliquées avec, mis à part de très rare cas (vraiment très rare) avec les versions récentes de PostgreSQL plus tu écris le SQL simplement et naïvement, et mieux ça se passe.
Des langages qui ont essayé de substituer au SQL, ça existe, mais aucun ne fait consensus, et à mon avis ce n'est pas pour rien: aucun de ceux que j'ai pu rencontrer ne permettait réellement d'être à la fois généraliste et d'abstraire des fonctionnalités avancées du SQL dans quelque chose de plus simple.
Je pense honnêtement, au vu de ce que ça permet de faire, que de concevoir un langage plus simple que le SQL pour le remplacer semble impossible, quant bien même il pourrait sûrement être amélioré (je pense notamment à la syntaxe horrible pour les accès au json). Il y a des cas où c'est possible et ça marche, mais c'est presque systématiquement des langage qui sont en fait des DSL (Domain Specific Language), conçus pour répondre à des problématiques métier, et qui par conséquent ne peuvent être utilisé en dehors.
Après, rien n'empêche d'imaginer un jour écrire un SQL-v2, qui soit une nouvelle langue plus moderne, mais je pense que sa complexité sera au moins équivalente au SQL lui même.