Bonjour,
Envoyé par
tbc92
Par exemple :
1
2
3
4
| select d.*
from demande d, signature_demande sd1, signature_demande sd2
where sd1.id_demande = d.id_demande and sd1.id_signature = 1 and sd1.accord = 1
and sd2.id_demande = d.id_demande and sd2.id_signature = 1 and sd2.accord = 0 |
D’accord. Comme l’écrit dans SQL and Relational Theory (pages 114, 115), celui qui est la référence en matière de relationnel, C. J. Date :
FROM t1 JOIN t2 ON bx
Est logiquement équivalent à
FROM t1, t2 WHERE bx
(Où bx est une expression booléenne représentant une condition de jointure).
Chacun est donc libre d’utiliser le style qu’il trouve à son goût, sans que quiconque trouve à y redire. Dans les deux cas, l’optimiseur d’un SGBDR digne de ce nom doit produire très exactement le même plan d’application.
Cela dit, chez DVP l’usage est d’utiliser le style « moderne », plus lisible, même si logiquement parlant c’est bonnet blanc et blanc bonnet. Bien que dinosaure ès bases de données, je m'y suis mis sans problème, ce qui n’empêche pas que dans mes échanges avec Date je conserve l'ancien style.
Envoyé par
CinePhil
Les
jointures s'écrivent depuis plus de 20 ans avec l'opérateur JOIN. Il serait temps de s'y mettre !
Des goûts et des couleurs : comme je viens de l’écrire, à chacun sa préférence.
1) Dans l’ouvrage cité ci-dessus, Date recommande tant qu’à faire d’utiliser NATURAL JOIN.
2) Pour ceux que ça peut intéresser, un bref rappel historique :
La version « classique » évoquée par tbc92 date de 1974, voyez l’article des pères de SQL, Boyce et Chamberlin (lesquels sont bien sûr partis des travaux de Codd) : SEQUEL: A structured English Query Language :
Q10. List rows of SALES and SUPPLY concatenated together whenever their ITEM values match.
SALES, SUPPLY
WHERE SALES. ITEM = SUPPLY.ITEM
La version moderne de la jointure (INNER JOIN, OUTER JOIN) date de 1983 (C. J. Date, The Outer Join. The 2nd International Conference on Databases. Cambridge, England. 1983. pp. 76-106). Date a repris son article en 1986 dans Relational Database Selected Writings “The Outer Join” ⁽¹⁾.
Syntaxe proposée par Date à cette époque :
1
2
| join-expression
::= [ OUTER | INNER ] JOIN relation-commalist on-clause |
Comme je ‘ai déjà signalé dans certaines discussions chez DVP :
Dans Relational Databases, Writings 1989-1991 ⁽²⁾, paru en 1992, C. J. Date écrivit par ailleurs (au chapitre 19, Watch Out for Outer Join, initialement publié dans InfoDB 5, No. 1 (Spring/Summer 1990)) :
I am glad to see that the SQL standards committees are in fact planning such an extension in their proposed follow-on to the existing SQL standard known as SQL2.
Les éditeurs de SGBD ont pris plus ou moins leur temps avant de proposer la construction INNER | OUTER JOIN. Par exemple, IBM ne l’a fait qu’en 1995, avec la version 4 de DB2 for MVS/ESA (autant dire en 1998 pour nous, pauvres utilisateurs, toujours en retard d’une version, contexte de production, plans de tests, de régression, etc. obligent). A la décharge d’IBM, la V3 de DB2 avait été livrée en 1993, et il n’était évidemment pas possible de la chambouler, d’envoyer au pilon des wagons de documentation prêts depuis un an, tout cela parce qu’en même temps naquit SQL/2.
Quant à ORACLE, il a fallu attendre 2002 (Oracle 9i) pour qu’il se mette à la norme.
Pour MySQL : je suis pas compétent pour répondre, mais vu sa date de naissance (1995 si j’en crois Wikipédia), il a sans doute dû prendre en compte la norme dès le départ.
Pour SQL Server : voyez SQLpro...
Etc.
P.-S. Attention les Anciens ! CinePhil va sortir sa sulfateuse, planquons-nous ! 
______________________
⁽¹⁾ Ouvrage (ISBN 0201141965) que l’on peut acquérir pour environ 10 euros (port compris), par exemple chez AbeBooks.
⁽²⁾ Ouvrage (ISBN 0201543036) que l’on aussi acquérir pour environ 10 euros (port compris), toujours chez AbeBooks
Requête SQL avec inner join incorrect
Répondre avec citation
Partager