Discussion :

[Invité]

Les normes SQL sont allégrement bafoué : entre du SQL SAS , SQL MySQl , SQL Access , SQL Oracle .

Un group_concat chez MySQL ? On va proposer un proc transpose chez SAS ! Une fonction VBA usine à gaz sur Access ...

Ne parlons pas des inner join / join et des diezes gauche ou droite avec les anciennes normes de chez Oracles. L'histoire du top ou du limit aussi est pas mal.

Chaque société a décidé de plus ou moins faire ses propres normes. Résultat chacun a pris le SQL avec ces normes à lui . Penser que tout changer ou harmoniser est possible ... est illusoire.

Lier 2 tableaux avec des join est plus facile que de faire boucler un tableau de 2 millions d'enregistrements sur un tableau de 1 millions d'enregistrement . Imaginez le nombre de combinaisons à tout comparer O.O

[SQLpro]

Les normes SQL sont allégrement bafoué : entre du SQL SAS , SQL MySQl , SQL Access , SQL Oracle .
…
Chaque société a décidé de plus ou moins faire ses propres normes.
...

Non, justement ce ne sont pas des normes, ni des standards, mais des dialectes.
Note que Oracle qui étais il y a encore quelques années, le plus indiscipliné, comble son retard :

• COALESCE à la place DE NVL
• CAST en remplacment des TO_...
• CASE pour DECODE
• L'arrivée des COLLATIONS, des noms longs et de l'opérateur APPLY….

A +

[MaximeCh]

Bump si quelqu'un a la réponse à mon léger HS... ça fait des mois/des années que je cherche à comprendre

[pboulanger]

si il n'aime pas SQL, il n'a qu'à utiliser un ORM...

[bullit75]

Quelques manques du SQL Standard ou présents mais pas déployés sur tous les SGBD à mon avis :

• XOR
• BOOLEAN et ENUM
• SYM_DIFF (pour compléter le UNION, INTERSECT et EXCEPT)
• CORRESPONDING
• LIKE ANY () / LIKE ALL ()
• Clauses WINDOW et QUALIFY des fonctions analytiques, WINDOW appelant une autre WINDOW https://modern-sql.com/caniuse/window_clause_chained
• Concaténation de chaînes avec “+”
• Fonctions d'agrégation personnalisées
• Manipulation de Tuples, dont comparaison
• INTERVAL et développements (OVERLAPS)
• IS DISTINCT FROM
• WHERE UNIQUE / DISTINCT
• SPLIT(String)
• JOIN USING
• CROSS/OUTER APPLY
• SEMI JOIN, ANTI JOIN
• Clause FILTER
• UPDATE avec JOIN
• UPDATE avec CTE
• Row Constructor
• MULTISET
• COLUMN DEFAULT résultat d’un calcul ou d'une fonction
• VIRTUAL COLUMN, MATERIALIZED VIEW
• ALTER TABLE ADD column AT POSITION n
• ORDER BY ... NULLS LAST/FIRST
• SIMILAR TO

Plus la division relationnelle comme décrite ici ; syntaxe proposée sur JOOQ :

TABLE_A
DIVIDE BY TABLE_B
ON [ some predicate ]

[SQLpro]

Quelques manques du SQL Standard ou présents mais pas déployés sur tous les SGBD à mon avis :
[...]

Plus la division relationnelle comme décrite ici ; syntaxe proposée sur JOOQ :

TABLE_A
DIVIDE BY TABLE_B
ON [ some predicate ]

La plupart de ce que vous avancez est disponible dans les grands SGBDR que sont IBM DB2, Oracle ou SQL Server, sous une forme ou une autre, ou encore via une combinaison simple d'opérateurs (certains fonctions peuvent être créée pour cela, de même qu'il est facile de créer des opérateurs nouveaux d'agrégation...).

Quand au cas de la division relationnelle, elle a été discutée, il y a bien longtemps peu avant le SQL la norme SQL 2 par le comité de normalisation. Mais le problème est qu'il existe 4 formes distinctes de division relationnelle... L'article cité n'en traite qu'une seul, révélant la pauvreté des affirmation que l'on trouve hélas fréquemment sur Internet..

• Division relationnelle exacte ou avec reste
• Division relationnelle quantifiée ou non

La combinaison de ces deux variantes montre bien 4 type de division relationnelle. L'article cité montre que l'opérateur présenté ne peut faire que des divisions exactes sans reste, un peu comme s'il était impossible sur une calculatrice de faire 7 / 2...

A +

[bullit75]

4 types de division, on est d'accord. Possibilité de faire une syntaxe (style mots-clé REMAINDER et QUANTIFIED à implémenter, ou plus), à voir, certains savent faire du design propre . Bien sûr, le diable se loge dans les détails, et on peut vite monter une usine à gaz, mais on a eu le même souci avec les types de jointures et il a été surmonté, alors...

Après, je ne connais aucun SGBD qui gère le XOR et la différence symétrique d'ensemble (style UNION). Or celles-ci restent quand même des éléments importants et leurs absences entraînent des requêtes lourdes à coder. Faire une fonction ou autre pour une opération logique de base me semble un peu aberrant.

Pour les autres, j'ai bien précisé que tous les SGBD n'intégraient pas tous les éléments, si Oracle par exemple propose un champ de type ENUM (plus BOOLEAN, vu que ce dernier est un ENUM à 2 valeurs prédéfinies) sans avoir à déclarer un type particulier en dehors de la table voire une mini-table de valeurs, j'appellerais ça un plus : On a de nombreux énumérateurs spécifiques à un champ qu'on n'a pas forcément besoin d'expliciter hors de la table, et faire un CHECK sur la liste de valeurs fait construction un peu artificielle.

EDIT : MySQL propose le XOR, mais la version que j'avais eu l'occasion de voir ne le proposait pas. Dont acte, il rentre dans les instructions que j'aimerais voir déployées dans tous les SGBD