Discussion :

[Gugelhupf]

Bon, je vais rajouter mon grain de sel :

• Bien que normé ANSI en 1986, le SQL existe depuis 1974, c'est un langage d'une grande maturité
• Depuis 2003 nous avons des mise à jour (des ajouts) de la norme tous les 2-3 ans, le langage est suivi
• Certaines technos NoSQL que j'ai pu voir ont commencés avec leur propre syntaxe, pour peu à peu s'orienter vers le SQL, c'est notamment le cas de CQL (le langage de Cassandra) ou bien N1QL (le langage de Couchbase), voulaient-ils s'approprier la popularité du SQL, ou bien le SQL a dès le départ été très bien conçu par les chercheurs d'IBM ?

Pour ma part le SQL a ses subtilités, le premier venu tombera forcément dans les pièges liées aux mélanges de jointures internes et externes ou des aggrégats par groupe, tout comme le débutant C et C++ qui utilisera les pointeurs... cependant je ne connais pas de langage qui permet de manipuler aussi bien les tableaux que le SQL

Si ces gens là voulaient vraiment montrer le bienfait de leur langage, ils mettraient en avant ce que leur produit apporte de plus, de mieux que le produit existant (ici le SQL), et je ne pense pas que ce soit le cas. Du coup j'ai plutôt l'impression de voir un groupe qui veut intégrer sa solution chez les clients pour vendre de l'audit

[Darkzinus]

La force du SQL c'est aussi d'être utilisable facilement par des non experts. Et globalement il répond à tous les besoins pourquoi devrait-on le remplacer ?

[stailer]

Comme dans toute appli, on a toujours les requêtes "simples"... quelques where, quelques group by.
Et puis le dév avance et il arrive le moment de la requête SQL compliqué : UNION , des vues, des filtres et des jointures avec INNER ou LEFT un peu partout parce qu'on a pas pu faire autrement... Et on a essayé de faire "bien" mais aussi un peu "vite" car les délais existent à un certain moment.

Tout ça pour dire que les exemple Malloy et compagnie c'est très joli, avec systématiquement des trucs hypers simples en exemple... Moi j'aimerais voir l'équivalent d'une bonne grosse query SQL comme on en a dans nos applis "réelles" et leur équivalent dans un autre langage.

Là seulement on pourra dire : ok l'écriture est 5 fois plus rapide et j'ai 5 fois moins de code de requête à écrire.

En attendant, lire l'équivalent d'un pauvre SELECT ... FROM table WHERE machin = 5 , il m'en faudra un peu plus pour me convaincre

[François DORIN]

Tout ça pour dire que les exemple Malloy et compagnie c'est très joli, avec systématiquement des trucs hypers simples en exemple... Moi j'aimerais voir l'équivalent d'une bonne grosse query SQL comme on en a dans nos applis "réelles" et leur équivalent dans un autre langage.

Exactement ! Par exemple, prendre les requêtes niveau hard de Datalemur, et comparer les requêtes SQL vs Malloy. Là, ce serait top !

[dfiad77pro]

Comme évoqué ,commencer par le FROM permettrait de résoudre pas mal de soucis de complétion coté IDE...
Mais il doit y'avoir un blocage sémantique qui créer un breaking change sinon SQL aurait été mis à jours pour supporter les 2 syntaxes

[Aurelien.Regat-Barrel]

Malheureusement, la réalité est que SQL est « suffisamment bon » pour la plupart des cas d'utilisation

Je suis allé vérifier le texte d'origine en anglais (en cas de mauvaise traduction) tellement je suis surpris d'une telle formule. Mais c'est bien ce qui est dit.

Je trouve très étonnant qu'un responsable de l'ingénierie regrette d'avoir un outil qui fasse bien le boulot. Mais il a été ingénieur commercial avant ça, ceci explique peut-être cela

[Invité]

Bonjour

SQL : en l'absence des MAJ importantes depuis des décennies, des critiques appellent à un remplacement du langage

Cette analyse sur le remplacement du langage SQL est-elle pertinente ?

Non pas du tout.

Partagez-vous l'avis selon lequel le SQL serait obsolète et nécessiterait une MAJ ?

On est en SQL 8 à ce que je sache ... Et chaque SGBD utilise plus ou moins son propre SQL (Access, SAS, My SQL, Cobol , Oracle ) ... Donc déjà faire évoluer un langage ou chaque boite qui développe un truc pond sa norme c'est juste impossible.

C'est comme si chaque entreprise développait son langage PHP ou C++ , je vous dis pas le bordel .

Quel langage de requête utilisez-vous ?

SQL , avec des complements en Excel, SAS , VBA , PHP , PQL , PL/SQL , noSQL

SQL, PRQL ou Malloy ?

SQL

Êtes-vous pour ou contre le remplacement de SQL par PRQL ou Malloy ?

On ne remplace rien vu que chaque langage bricole un truc . En gros le SQL n'est plus normé ^^

Selon vous, est-ce possible ?

PAs du tout.

[petitours]

Changer pour changer parce que ne pas changer serait mal ?

Argumenter qu'il y aurait des choses à améliorer oui, argumenter que ça ne "change pas" est juste la plaie.

[escartefigue]

On ne remplace rien vu que chaque langage bricole un truc . En gros le SQL n'est plus normé

Le SQL est normé, mais chaque SGBD en propose un dialecte plus ou moins proche de cette norme.
Malgré tout, ces divergence ne sont pas majeures, on en vient facilement à bout.
Et ce ne sont pas les tuto qui manquent, à commencer par ceux proposés ici sur Developpez.net, dont certains sont de grande qualité.

[Invité]

Bonjour,

Le SQL est normé, mais chaque SGBD en propose un dialecte plus ou moins proche de cette norme.
Malgré tout, ces divergence ne sont pas majeures, on en vient facilement à bout.
Et ce ne sont pas les tuto qui manquent, à commencer par ceux proposés ici sur Developpez.net, dont certains sont de grande qualité.

D'ailleurs à part le SQL , quel autre langage a autant de variante en fonction du logiciel ou l'on l'utilise ?

[AoCannaille]

D'ailleurs à part le SQL , quel autre langage a autant de variante en fonction du logiciel ou l'on l'utilise ?

VB. Le plus drôle c'est que les différentes versions viennent du même éditeur pour tourner sur l'os du même éditeur.

[SQLpro]

Genre de discussion débilo-stérile et papier torche cul que j'adore...

Remplacer un langage qui a fait l'objet de dizaines voire de centaines d'année homme en R&D pour l'optimiser par un nouveau langage qui nécessitera avant d'être réellement performant, quelques dizaines d'année et obligera des millions de bases de données avec l'inertie du volume des données dedans à changer, c'est aussi stupide que de dire que les soucoupe, volante dont la forme est plus harmonieuse devraient s'imposer dans le ciel, parce que cela choquerait moins l’œil !

Je vous laisse méditer et me maudire à coup de - ... ce qui ne changera rien au problème, mais montrera que bien des participants à ce forums sont victime de l'effet Dunning-Kruger

« Le plus grand ennemi de la connaissance n'est pas l'ignorance mais plutôt l'illusion de la connaissance »
Stephen Hawking


A +

[petitours]

Je vous laisse méditer et me maudire à coup de - ... ce qui ne changera rien au problème, mais montrera que bien des participants à ce forums sont victime de l'effet ^{Dunning-Kruger}

Dunning-Kruger explique a lui seul pourquoi il y a tant de projets concurrents et tant qui sont abandonnés plus ou moins vite.
Très vite on croit tout savoir et on veut faire mieux => nouveau super langage concurrent.
Puis en le faisant on réalise l'étendue de la complexité du truc, on redescend de la fameuse montagne => abandon du projet.

[jmc_plus]

Ce qui me rassure, c'est de constater que je ne suis pas le seul à être très réticent à virer un truc que bon nombre savent utiliser, qui fonctionne et qui fait tout le travail qu'on lui demande par un machin dont on ne sait pas grand chose.

[Norbertus 10]

Sql n'est pas un langage procédural et pour l'avoir utilisé un peu en production-exploitation de bases de données, il est incontournable pour la maintenance des Sgbdr, mais aussi pour la gestion des entreprises pour connaitre des statistiques de ventes ou financières ou modifier une adresse de livraison en temps réel.
Néanmoins ses performances peuvent être limitées du fait de la fragmentation des disques et des données, le chainage des tables, de trop nombreux index, etc..

L'intégration de Sql dans les langages procéduraux est tributaire de la compilation ou de l'interprétation des instructions Sql par ces langages et il peut donc s'avérer nécessaire pour certains de modifier des éléments des requêtes pour améliorer les performances (PLSQL pour avoir programmé avec pendant quelque temps est de mon point de vue le meilleur exemple d'embended Sql). En quoi ça devrait modifier le langage Sql normes Ansi?

Faut-il commencer les instructions Sql dans certains langages par le nom de la table ou par l'équivalent de select pour améliorer les performances? ça dépend peut-être des contraintes de ces langages. Un peu comme dans certaines langues germaniques où on commence par nommer l'objet (j'ai du lait acheté) et d'autres où on commence par l'action (j'ai bu du lait), quoique en fait si on commence par nommer l'objet, ça restreint le champs des possibles.
En effet, on peut boire, bouillir, acheter, vendre le lait, mais si on commence par l'action, on peut boire de très nombreux breuvages (eau, vin, lait, sirop, apéritif, jus de fruit, etc..) mais ça relève sans doute d'avantage des experts en IA.
Que l'on remplace le signe "=" par un "?", ça ne change rien et il y a autant de caractères. D'ailleurs la frugalité linguistique a peu de point communs avec le langage Sql sans quoi au lieu d'écrire "beaucoup" on écrirait "bocu" comme dans de nombreuses langues.
(En allemand le "¨" permet de changer le son "u" en "ou", en espagnol la tilde permet d'économiser une lettre dans le son "gn" mais ils pourraient encore simplifier en remplaçant partout le son "ye" rendu en français par "ill" et en espagnol par "ll" avec un simple "y" comme dans "ayer").
Peut-être que les langages de programmation varient selon les traditions culturelles et les contraintes linguistiques selon les continents, mais les boucles conditionnelles commencent par un "if" ou équivalent et finissent par un "endif" ou un équivalent.
Sql est un langage simple et génial, universel, tout comme les balises Html, après, a chacun de l'intégrer selon ses nécessités.. et possibilités.

[SQLpro]

...
Néanmoins ses performances peuvent être limitées du fait de la fragmentation des disques et des données, le chainage des tables, de trop nombreux index, etc..

Dans ce cas c'est un problème de DBA et donc de mauvaise administration. La gestion du stockage (capacity planning) comme la maintenance pour défragmenter et reconstruire index et statistiques est absolument fondamentale et je passe mon temps en audit à rectifier inexistante deu B A BA de la maintenance !

A +

[Norbertus 10]

oui, absolument, mais y-a-t-il assez de dba, de toutes façons le tuning est désormais automatisé depuis 20 ans, (cf les bases Oracle depuis la version 8i)

néanmoins un concepteur de langages ne peut ignorer les contraintes de performances dues à l'environnement dans lequel il développe un langage et quoiqu'il en soit les performances de Sql sont tributaires aussi des compilateurs et interpréteurs des langages procéduraux qui intègrent des requêtes Sql (les curseurs PlSql sont très performants) et des connecteurs (cf Odbc et Sqlj par exemple)

[Waldar]

En phase avec ce qui a été dit avant, c'est pas parce que c'est ancien que c'est obsolète.

Il y a quelques domaines très précis où SQL n'est pas parfait et il son côté déclaratif est pesant, c'est quand on souhaite appliquer des fonctions à l'intégralité des données.
Par exemple, sur une table de 30 colonnes, si je veux remplacer tous les nulls par 0, il faut coder tous les coalesces colonne par colonne.
En python on tape df.fillna(0) et c'est fini.
Idem pour les pivots, si on a 1000 colonnes à pivoter rien que la taille du code SQL est problématique.

[escartefigue]

oui, absolument, mais y-a-t-il assez de dba, de toutes façons le tuning est désormais automatisé depuis 20 ans, (cf les bases Oracle depuis la version 8i)

Les automatismes, c'est bien, mais ça ne suffit pas toujours, les DBA sont la pour les cas où justement ces automatismes ne suffisent pas.

néanmoins un concepteur de langages ne peut ignorer les contraintes de performances dues à l'environnement dans lequel il développe un langage et quoiqu'il en soit les performances de Sql sont tributaires aussi des compilateurs et interpréteurs des langages procéduraux qui intègrent des requêtes Sql (les curseurs PlSql sont très performants) et des connecteurs (cf Odbc et Sqlj par exemple)

Le moteur du SGBD-R tient compte de son environnement, puisque l'optimiseur (rien à voir avec SQL), pour une même requête, choisit sa stratégie en fonction notamment des index installés, des volumes de chaque table, du facteur de filtrage et autre éléments statistiques qui diffèrent d'une plate forme à l'autre (typiquement, entre la production et la recette, la même requête peut donner des stratégies différentes).
Le langage SQL n'est pas directement concerné puisqu'il ne sert qu'à transmettre une instruction au moteur du SGBD-R qui lui fera ce travail d'optimisation.
Par contre, le choix de tel ou tel type d'instruction SQL par le développeur influence directement les perfs (à commencer par l'utilisation de prédicats "sargables").

[Norbertus 10]

Tout à fait d'accord, il y a des limites dont certaines sont liées à la sécurité des bases de données, il faut mieux être obligé de modifier colonne par colonne que toutes les colonnes d'une table à la fois.
Je n'ignore pas que l'on est souvent sous pression et qu'il faut aller vite mais quand un programmeur (j'ai commencé comme analyste programmeur avec Power Builder et Forms)veut faire une modif à chaud (et souvent directement en prod (pourquoi avoir un environnement de test), après c'est le dba qui doit reconstruire la table, récupérer les données, c'est un vrai bazard).
Tant mieux si Python utilise une seule fonction (génial, sauf les retours à la ligne tabulés parce quand on fait une modif il faut compter le nombre de tabulations pour ne pas avoir d'erreur de compilation), on peut faire les coales de diverses façons y compris avec du Sql, mais je ne suis pas prof d'informatique ni consultant.
Pour une comparaison, je dirais que je préfère qu'un moteur de voiture, de vélo électrique ou de patinette fasse du bruit (c'était obligatoire pour signaler aux povs piétons qu'un engin est proche)

NB:
on peut importer la table et dans un simple fichier texte et faire un coalesce de toutes les colonnes en une fois

Sql a un grand avenir devant soi pour la gestion des données des entreprises en temps réel et y compris pour des requêtes sur des tables partitionnées gigantesques et réparties sur plusieurs serveurs, bonne continuation