differnce entre jointures classiques et jointure normalisées

bonjour
je travaille sous Oracle 9
jai un resultat de requete que je n'explique pas

jai 3 table a, b et c liées par integrité referentielle

chacune delle a une colonne appelée dtdeff

donc losque jexecute la requete suivante

Code:

---

1 2 3 4

SELECT dtdeff FROM A,B, C WHERE A.fkb = B.pkb AND B.fkc = c.pkc

---

jai un

Citation:

---

Ora 00918 : definition de colonne ambigue

---

ce qui est normal car je nai pas specifié la table d'ou provient le dtdeff
jusque la je comprends ....


par contre quand jexecute la meme requete mais avec des jointures normalisées sans specifier lorigine de ma dtdeff

Code:

---

1 2 3 4

SELECT dtdeff FROM A inner join B ON A.fkb = B.pkb inner join C ON B.fkc = c.pkc

---

je ne pas de message derreur et il me ramene les dtdeff de B !!!!

alors la je ne comprends plus rien ....
pourkoi je nai plus de message derreur ora00918 ????
pour me remène t il les dtdeff de la table B ???
pourquoi pas les dtdeff de la table A ?? ou C ????

cest vrai kil suffirai que je fasse

Code:

---

1 2 3 4

SELECT A.dtdeff FROM A inner join B ON A.fkb = B.pkb inner join C ON B.fkc = c.pkc

---

pour solutionner mon probleme...
mais jaime bien comprendre les truc ;-)
si kelkun a une idée ....

Bonjour,

C normal tu ne selectionne le champ dtdeff que de A

Citation:

---

SELECT dtdeff
FROM A

---

par contre moi ce qui m'etonne (mais j'ai lu en diagonale...)
c que

Code:

---

inner join C ON B.fkc = c.pkc

---

ne t'insulte pas ?

:tagcode:

S'il ne ramène que les dtdeff de B c'est pour optimiser la requête. En effet, la table B est utilisée dans les deux jointures AB et BC, il est donc plus simple pour Oracle de ramener les dtdeff de B issus de la première jointure avec A, puis d'effectuer la seconde jointure avec C (ou l'inverse : BC puis AB).

Re,

ça me bluffe ton truc ...
Je ne savais pas qu'on pouvait écrire ça comme ça.
Sympa d'avoir expliqué ... au moins je me coucherais moins ignorant ce soir ;-)

C'est visiblement un bug d'Oracle.

En effet en cas d'ambiguité sur le nom de la colonne, la requête devrait ne pas être exécutée et retourner une erreur de syntaxe.

A +

pas du tout, c'est extrémement logique :

Code:

---

1 2 3 4

SELECT dtdeff FROM A inner join B ON A.fkb = B.pkb inner join C ON B.fkc = c.pkc

---

Signifie : je sélectione dtdeff de la table A selon les jointures décritres via INNER JOIN. Tout cela est donc parfaitement logique :)

En revance :

Code:

---

1 2 3 4

SELECT dtdeff FROM A,B inner join C ON B.fkc = c.pkc WHERE A.fkb = B.pkb

---

Doit bien retourner une erreur si dtdeff est également dans B ;)

orafrance qu'en tu dis :

Citation:

---

pas du tout, c'est extrémement logique :

Code:

---

1 2 3 4

SELECT dtdeff FROM A inner join B ON A.fkb = B.pkb inner join C ON B.fkc = c.pkc

---

Signifie : je sélectione dtdeff de la table A selon les jointures décritres via INNER JOIN. Tout cela est donc parfaitement logique :)

---

Moi cela ne me parait pas tres logique car ce n'est pas la date de A ki est retourné .......

SELECT dtdeff, A.dtdeff, B.dtdeff, C.DTDEFF
FROM A
inner join B ON A.fkb = B.pkb
inner join C ON B.fkc = c.pkc

donne :

DTDEFF A.DTDEFF B.DTDEFF C.DTDEFF
01/09/2004 20/06/2005 01/01/2005 01/09/2004
[/code]
de plus entre hier et aujourdhui les resultats ont changé, le jeu dessai n'est plus le meme ....
Hier il me retourné la date de B, aujourdhui avec la meme requete cest la date de C ........


:?: :?: :?:

8O ha oui... là effectivement c'est moins logique... :aie:

Ce qui est logique à mon sens c'est que l'écriture normalisée permet de mieux maitriser ce qui est sélectionnée ;)

Je vais voir du coté du spport si je trouve quelque chose :)

tu aurais le plan d'exécution STP :)

En fait, celui en écriture normalisé et l'autre ;)

D'après les témoignages sur Metalink qu'Oracle sélectionne la valeur de la dernière table jointe... pourquoi pas après tout :mouarf:

Essaye :

Code:

---

1 2 3 4 5

SELECT dtdeff FROM A inner join C ON B.fkc = c.pkc inner join B ON A.fkb = B.pkb

---

Est-ce bien b.dtdeff qui est sélectionnée ?

merci pour tes recherches Orafrance
pour ton premier message : le plan de la requete avec les jointures normalisées et le plan de la requete avec les jointures classique sont exactement identiques , cest a dire :

Code:

---

1 2 3 4 5 6 7 8 9

SELECT STATEMENT Hint=CHOOSE NESTED LOOPS | NESTED LOOPS | | INDEX FULL SCAN INDEX de la pk de A | | TABLE ACCESS BY INDEX ROWID de la TABLE B | | INDEX UNIQUE SCAN INDEX de la pk de B | TABLE ACCESS BY INDEX ROWID de la TABLE C | INDEX UNIQUE SCAN de la pk de C

---

pour ce ki est de 2eme ton message il n'est pas possible de faire comme tu le dis :

Citation:

---

SELECT dtdeff
FROM A
inner join C ON B.fkc = c.pkc
inner join B ON A.fkb = B.pkb

---

jai un ora 00904 --> idendtificateur non valide

en effet mon SCHEMA est le suivant :

Code:

---

1 2 3 4 5 6 7 8 9

+--------+ +--------+ +--------+ | A | | B | | C | +--------+ +--------+ +--------+ | pkA | +------>| pkB | +----->| pkc | | fkB |--+ | fkc |--+ | | | dtdeff | | dtdeff | | dtdeff | | ... | | ... | | ... | +--------+ +--------+ +--------+

---

je n'ai pas de lien direct entre A et C , je dois donc commencer par le inner join sur B puis le inner join sur C !!

la verité est donc ailleurs :cry:
mais ou ?????



[/img]

ceci étant... au risque de pareil un peu tatillon, on se demande pourquoi dtdeff est dans toutes les tables... Orafrance ou l'art de détourner l'attention :aie:

Bon... je vais continuer de creuser :?

Je ne pensais pas que l'ordre de jointure avait de l'importance... voila qui ajoute une contrainte non dégligeable mais une qualité de lecture non moins négligeable ;)

Citation:

---

Envoyé par orafrance

Je ne pensais pas que l'ordre de jointure avait de l'importance... voila qui ajoute une contrainte non dégligeable mais une qualité de lecture non moins négligeable ;)

---

bah idem...

je viens de tester sur des requete avec des plans d'execution assez grands... et l'inversion des tables dans la clause from ou l'inversion des jointures dans la clause WHERE ne change rien ....
et quelque soit le type de jointure...

Normalement l'optimiser de la base remet les clauses from et where en ordre avant l'execution ... non ? :?

Quand on utilise le mot clé 'JOIN' l'ordre des jointures à de l'importance.
Quand on fait des jointures dans la clause WHERE, l'ordre n'a pas d'importance.

mouais
jai limpression kil doit s'agir dun bugg ORACLE, je n'ai pas dexplication plus logique .......

:?