Discussion :

[esperanto]

Encore une fois il s'agit d'apprendre le SQL !.

Bon, vu que tous les DBA SQL persistent à (faire semblant de) ne pas comprendre:
ok ça va calmez vous oubliez le mot difficile et remplacez par : beaucoup trop verbeux eu égard au fait que ce type de requête est plutôt fréquent. ça va comme ça?
Non? ok je précise encore

Répéter trois fois "select * from R1", c'est un coup à faire des erreurs (encore ici on a de la chance que tous les select aient la même liste de colonnes...)
N'importe quel langage de programmation a aujourd'hui un opérateur OU PARESSEUX (si quelqu'un a une meilleure traduction je suis preneur) qui correspond précisément à cette requête.
Il m'aurait paru logique d'écrire quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from demo where src = ? or else src like ?

ou, pour avoir plus de souplesse (je rajoute un champ juste pour montrer l'intérêt)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(select *, 'exact' as type from demo where src = ?) or else (select *, 'fuzzy' as type from demo src like ?)

Avant de hurler, oui je sais c'est pas du SQL, c'est juste ce que n'importe quel langage de programmation digne de ce nom aurait permis de faire.
Ah oui mais SQL n'est pas un langage de programmation, c'est sûrement ça...

C'est bien le fond du problème. La cohérence c'est l'acidité des transactions, le rafraîchissement de bases c'est autre chose (copie, backup, peu importe).
La cohérence n'est jamais sacrifiable car c'est l'enfer de redresser une base incohérente (entrepôt de données à part).

Si tu fais toujours des recherches exactes, sans doute. Dans le monde de la traduction, en revanche, on fait beaucoup de recherches approchantes (objectif: permettre à un traducteur de s'inspirer de textes similaires traduits il y a longtemps) et là je préfère de loin que le traducteur voit des exemples datant de plusieurs mois (et qui ont donc été validés depuis longtemps) plutôt que de le voir quitter l'application parce qu'à chaque phrase traduite il perd dix secondes parce que le système attend que tous les nœuds aient confirmé le commit avant de rendre la main.
En plus dans notre cas c'est d'avantage des INSERT et très peu d'UPDATE, donc la synchronisation à postériori (faite pendant la nuit de façon automatique) ne présente pas beaucoup de difficultés.
Je ne prends pas ce cas pour une généralité, je dis juste que la contrainte de cohérence n'en est pas une dans certains cas.

Et moi non plus je ne jette pas complètement SQL, je préfère juste varier les outils suivant le problème posé plutôt que de partir du principe que tout doit être fait à l'identique.

[SQLpro]

…
Les seuls qui font des cubes sont les clients SQL-Server.

Ceux qui ont d'autres bases n'en ont pas besoin, un datamart étoile / flocon bien modélisé et bien implémenté fait très bien le job.

Note bien que SQL Server est revenu là dessus en proposant le mode Tabular…. Quand à la BI temps réel, donc sur des bases OLTP, ça se fait de plus en plus chez MS via le "In Memory" ou les index verticaux. Sur ces sujets MS est d'ailleurs plus pointu que son principal concurrent Oracle…

A +

[Michel.Priori]

Ah oui mais SQL n'est pas un langage de programmation, c'est sûrement ça...

Tu connais beaucoup de langages qui passent par la création d'un plan d’exécution avant compilation puis exécution ?
En dehors du SQL bien sûr.

L'avantage du SQL c'est qu'il y a une norme derrière.
Si l'idée proposée est lumineuse, elle n'aura aucun mal à être intégrée à la norme.

[esperanto]

Tu connais beaucoup de langages qui passent par la création d'un plan d’exécution avant compilation puis exécution ?

Pour moi, un plan d'exécution, c'est une forme de compilation (ou d'optimisation pendant la compilation, si tu préfères): ça consiste à convertir ta requête en quelque chose que la machine exécute plus facilement - ça produit le même résultat même si ça le fait en utilisant d'autres étapes que celles que le programmeur avait prévu. Compiler, ce n'est pas forcément traduire vers l'assembleur natif de ta machine. C'est un peu comme si ton serveur était une machine virtuelle, le EXPLAIN PLAN convertissant juste les expressions compilées en quelque chose de lisible par un humain.

L'avantage du SQL c'est qu'il y a une norme derrière.

L'avantage par rapport à quoi?
NoSQL c'est peut-être encore vaste mais on voit quand même se dégager des tendances: les bases XML (et XML c'est une norme), les bases JSON (et JSON c'est une norme)... après c'est vrai qu'il n'y a pas encore de langage de requêtes normalisé pour XML ou JSON, mais si ce genre de bases tend à se généraliser, ça viendra.

[Michel.Priori]

Pour moi, un plan d'exécution, c'est une forme de compilation (ou d'optimisation pendant la compilation, si tu préfères)

"Pigeons, cochons, ... tout ça c'est de la volaille"
Le fait que l'algorithme de résolution soit choisi en fonction de sa qualification n'est pas de même nature que l'optimisation de l’exécution !

[Michel.Priori]

L'avantage par rapport à quoi?
[...]et JSON c'est une norme

La norme n'est rien en soit. C'est le processus normatif qui est important. Le second amenant au premier.

TCP/IP n'est pas parfait non plus.
Comment se passent les évolutions ?
Est-ce que c'est un frein ou un gage d'évolution pérenne ?

Donc oui, être adossé à une norme c'est un avantage.

[SQLpro]

... les bases XML (et XML c'est une norme), les bases JSON (et JSON c'est une norme)...

NON, NON et NON… tois fois non !

Les SGBD XML ont existés au début des années et sont tous morts par darwinisme. Le dernier en date était Tamino d'AG Software… Compte tenu de la verbosité du stockage le volume des données stockées était le triple de celles des SGBDR et les performances catastrophique car il est extrément difficile d'indexer du XML….
Quant au XML et au JSON, ce ne sont absolument pas des normes… mais des standards. Il y a une différence fondamentale :

Les normes sont validés par des organismes coopératifs (des industriels qui se réunissent) et publiés de manière officielle (AFNOR en France, ANSI aux USA, et finalement ISO au niveau international).
Le langage SQL est une norme ISO (9075) compte tenu de sa très vaste utilisation et de sa longévité, longévité et donc pérennité acquise, justement du fait du cadre normatif… Autres exemple : SGML (ISO 8879)

Les standards sont décidés par une entreprise ou un organisme, sans concertation, et publié à titre personnel. Il peuvent être fermé (droits à payer, exemple en TV les standards PAL SECAM, NTSC) ou ouverts (donc gratuits comme HTML : https://html.spec.whatwg.org/multipage/, XML : https://www.w3.org/XML/ ou encore OGC http://www.opengeospatial.org/docs/is)

A +

[esperanto]

il est extrément difficile d'indexer du XML….

Ah bon? Pourtant il suffit de lire la doc
(ben quoi? moi aussi je peux faire comme vous et prendre ce que vous dites au pied de la lettre pour conclure ce qui m'arrange...)

[AoCannaille]

Les normes sont validés par des organismes coopératifs (des industriels qui se réunissent) et publiés de manière officielle (AFNOR en France, ANSI aux USA, et finalement ISO au niveau international).
Le langage SQL est une norme ISO (9075) compte tenu de sa très vaste utilisation et de sa longévité, longévité et donc pérennité acquise, justement du fait du cadre normatif… Autres exemple : SGML (ISO 8879)

Les standards sont décidés par une entreprise ou un organisme, sans concertation, et publié à titre personnel. Il peuvent être fermé (droits à payer, exemple en TV les standards PAL SECAM, NTSC) ou ouverts (donc gratuits comme HTML : https://html.spec.whatwg.org/multipage/, XML : https://www.w3.org/XML/ ou encore OGC http://www.opengeospatial.org/docs/is)

A +

Merci pour ce rappel, A chaque fois que je corrige quelqu'un en parlant de la différence entre Norme et Standard je sais faire exactement ces deux définitions, mais je les inverses régulièrement, du coup après une longue tirade ça fini toujours par "Ou l'inverse, peu importe, en tout cas c'est différent!" ce qui décrédibilise quelque peut la pertinence des propos

[Pyramidev]

Quant au XML et au JSON, ce ne sont absolument pas des normes… mais des standards. Il y a une différence fondamentale :

Les normes sont validés par des organismes coopératifs (des industriels qui se réunissent) et publiés de manière officielle (AFNOR en France, ANSI aux USA, et finalement ISO au niveau international).
Le langage SQL est une norme ISO (9075) compte tenu de sa très vaste utilisation et de sa longévité, longévité et donc pérennité acquise, justement du fait du cadre normatif… Autres exemple : SGML (ISO 8879)

Les standards sont décidés par une entreprise ou un organisme, sans concertation, et publié à titre personnel. Il peuvent être fermé (droits à payer, exemple en TV les standards PAL SECAM, NTSC) ou ouverts (donc gratuits comme HTML : https://html.spec.whatwg.org/multipage/, XML : https://www.w3.org/XML/ ou encore OGC http://www.opengeospatial.org/docs/is)

Aurais-tu une source sur cette différence de sémantique ?
Je viens de regarder standard et norme dans plusieurs dictionnaires français, dont le TLF, et je n'ai pas vu tes définitions.
Idem pour standard et norm dans un dictionnaire anglais (Oxford English Dictionary).

[Michel.Priori]

Un "standard" peut être de fait.
Une "norme" non.

[esperanto]

mais des standards. Il y a une différence fondamentale :

Et cette différence entraine quoi? Franchement, en dehors du monde universitaire, je me vois mal dire à mon patron "je ne vais pas implémenter JSON parce que c'est un standard et pas une norme". Surtout qu'il n'existe pas de norme remplissant le même objectif: qu'est-ce qu'on peut y faire si l'ISO ne s'est pas intéressé au problème des formats de sérialisation?
Et puis franchement, je préfère encore les "recommandations" du W3C à l'insipide "norme" OpenXML (tiens, ça les a pas gênés que XML soit pas une norme du coup...) qui n'a été validée que parce que son promoteur donnait un peu plus d'argent à l'ISO que les autres...

Tiens au passage, Unicode c'est un standard ou une norme d'après ta définition? Attention il y a un piège...

[Michel.Priori]

Franchement, en dehors du monde universitaire, je me vois mal dire à mon patron "je ne vais pas implémenter JSON parce que c'est un standard et pas une norme".

Comme disait ma grand-mère : "s'il avait fallut les attendre pour inventer le fil à couper le beurre, on le couperait encore à la hache."
Heureusement que l'invention et le progrès n'est pas "normatif" !

Pour autant, et c'est l'objet du post, attaquer de front un standard existant pour dire qu'il mérite une mise à jour majeure est soit l’œuvre d'un génie (et faut pas imaginer qu'il n'en n'existe pas) soit un élan d'humeur d'un trublion.
Ça se discute. Ça s'arbitre.

Quand on voit que l'adoption de l'écriture des JOIN, norme 1992, n'est toujours pas adopté par certains programmeurs Oracle (de moins de 20 ans, sinon c'est pas drôle), je me dis que si c'est pour faire pareil en mieux, il y a de fortes chances pour que ça reste lettre morte pour un bout de temps.

Et cette différence entraine quoi?

Où en est la bataille entre le PAL et le SECAM ?
Où en est la norme IEEE 802.5. ?

Je répète, l'avantage d'une norme, est que les challenges sont protocolairement prévus.
C'est ce protocole d'intégration de la nouveauté qui est un avantage.
En soit, la norme n'est pas un but et ne confère absolument rien si l'adoption n'est pas au rendez-vous.

Les normes "actives", c'est à dire, pour lesquelles il y a des participants et des enjeux (je pense notamment au réseau téléphonique 2g, 3g, 4g, 5g ...) les évolutions ne manquent pas.

La question qui me vient est : pourquoi cette proposition n'est pas une proposition auprès de l'agence ANSI ?

[pboulanger]

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

[SQLpro]

Et cette différence entraine quoi? Franchement, en dehors du monde universitaire, je me vois mal dire à mon patron "je ne vais pas implémenter JSON parce que c'est un standard et pas une norme". Surtout qu'il n'existe pas de norme remplissant le même objectif: qu'est-ce qu'on peut y faire si l'ISO ne s'est pas intéressé au problème des formats de sérialisation?
Et puis franchement, je préfère encore les "recommandations" du W3C à l'insipide "norme" OpenXML (tiens, ça les a pas gênés que XML soit pas une norme du coup...) qui n'a été validée que parce que son promoteur donnait un peu plus d'argent à l'ISO que les autres...

Tiens au passage, Unicode c'est un standard ou une norme d'après ta définition? Attention il y a un piège...

fait un petit effort intellectuel. Relit ce que j'ai dit !

Quand aux questions piège à con, j'ai d'autres chats à fouetter !

A +

[escartefigue]

Quand on voit que l'adoption de l'écriture des JOIN, norme 1992, n'est toujours pas adopté par certains programmeurs Oracle (de moins de 20 ans, sinon c'est pas drôle), je me dis que si c'est pour faire pareil en mieux, il y a de fortes chances pour que ça reste lettre morte pour un bout de temps.

Pas seulement Oracle, loin s'en faut

Et pire : nombreux sont les enseignants à encore ignorer l'usage de l'opérateur JOIN et qui donnent des cours en codant les jointures dans le WHERE

[MaximeCh]

Les optimiseurs rendent la nuance syntaxique inopérante depuis un moment, non?
Sinon, pour l'adoption du SQL moderne, il reste encore des progrès à faire c'est sûr.

[escartefigue]

Les optimiseurs rendent la nuance syntaxique inopérante depuis un moment, non?

Depuis toujours, mais la lecture des requêtes en est facilitée, surtout pour Oracle qui avait proposé une syntaxe particulière qui peut déconcerter les développeurs ayant une culture non Oracle

[MaximeCh]

D'ailleurs quelque chose qui m'embête depuis un moment : est-t-il possible de garder la syntaxe join uniquement, et ne pas utiliser where, quand il y a un cycle dans le chemin de jointure?

Nvm, TIL, c'est possible, au moins avec postgresql.
Il suffit de fermer le cycle dans le dernier "join on and" une fois que toutes les tables impliquées ont été déclarées dans leurs clauses join respectives.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
select * 
from tabA 
join tabB on tabA.id=tabB.id
join tabC on tabB.id=tabC.id and tabC.id=tabA.id
;

[Waldar]

Depuis toujours, mais la lecture des requêtes en est facilitée, surtout pour Oracle qui avait proposé une syntaxe particulière qui peut déconcerter les développeurs ayant une culture non Oracle

Oracle avait le (+) sur les colonnes, mais Sybase et SQL-Server avaient le =* au niveau de l'opérateur.
On ne peut pas reprocher aux éditeurs de trouver des solutions aux problèmes réels, et c'est en ça que la norme SQL est importante, elle permet de converger vers une syntaxe de plus en plus ressemblante.
Mais ça n'empêchera pas les éditeurs de déployer de nouvelles fonctionnalités avec de nouvelles syntaxes, ce qui est in fine une bonne chose.