Discussion :

[fopicht]

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 :

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

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

jai un

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 :

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

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 :

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

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 ....

[TheLeadingEdge]

Bonjour,

C normal tu ne selectionne le champ dtdeff que de A

SELECT dtdeff
FROM A

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

Code :

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

inner join C ON B.fkc = c.pkc

ne t'insulte pas ?

[orafrance]

[heffer69]

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).

[TheLeadingEdge]

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 ;-)

[SQLpro]

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 +

[orafrance]

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

Code :

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

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 :

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

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

[fopicht]

orafrance qu'en tu dis :

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

Code :

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

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 ........


: : :

[orafrance]

ha oui... là effectivement c'est moins logique...

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

[orafrance]

tu aurais le plan d'exécution STP

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

[orafrance]

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

Essaye :

Code :

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

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 ?

[fopicht]

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 :

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

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 :

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 :

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

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]

[orafrance]

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

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

[booth]

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 ?

[heffer69]

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.

[fopicht]

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