Discussion :

[elreybubu]

Bonjour
Alors voila pour resumé mon problème, j'ai 2 tables.

Une table A avec la clé primaire id_A
et une table B qui contient un champs champ_B et id_A

Les tables A et B sont en liaison (1,n) pour une ligne de A, plusieurs lignes de B

Alors ce que je veux faire c'est de choisir les lignes de la table A qui n'ont QUE champ_B=12 par exemple.
Quelqu'un aurait il une idée de la facon de mettre cela en place?

Merci d'avance

[plaineR]

Avec une clause exists par exemple :

Code :

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

1
2
3
4
5
6
select *
from tableA a
where exists (select null 
              from tableB b 
              where b.idA=a.idA 
                and champB=12);

[Alain B.]

Je me demande si

Code :

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

1
2
3
4
select a.*
from tableA a,tableB b
where b.idA=a.idA 
                and b.champB=12);

ne serait pas un peu plus 'optimum'

[nuke_y]

Certes si on considère qu'il n'existe qu'une seule ligne dans B pour laquelle champ_B=12, sinon ça duplique A et il faut mettre un distinct, et ça coûte plus cher.

[plaineR]

Je me demande si

Code :

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

1
2
3
4
select a.*
from tableA a,tableB b
where b.idA=a.idA 
                and b.champB=12);

ne serait pas un peu plus 'optimum'

Pas forcément. Il faut pour cela étudier le plan d'exécution. Il n'y a pas de règles toute faite. Mais de manière générale, la clause exists est plus performante.

[elreybubu]

Bonjour,
Merci pour vos réponses, mais je pense que mon exemple avec mes tables A et B ne correspondait pas vraiment avec ce que je souhaitait reelement faire.
Après quelques bon retournement du cervelet gauche j'ai réussi à troouver une soultion :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
SELECT * FROM ENTETE_OP WHERE NUM_OP IN ( 
                  SELECT DISTINCT NUM_OP FROM LIGNE_COLISEE 
                  WHERE NUM_OP IN (
                             SELECT NUM_OP FROM LIGNE_COLISEE  
                             WHERE (ID_PRODUIT=039353 OR ID_PRODUIT=636673                     
                                   OR ID_PRODUIT=636700 OR ID_PRODUIT=637464)
                                   AND ID_SOCIETE='PF'
                  MINUS
                             SELECT  NUM_OP FROM LIGNE_COLISEE  
                             WHERE ID_PRODUIT<>039353 AND ID_PRODUIT<>636673 
                                 AND ID_PRODUIT<>636700 AND ID_PRODUIT<>637464
                                 AND ID_SOCIETE='PF'
                  )
)

Bon voila je pense que vous vous en doutez, cette requete n'est pas du tout optimiser, j'obtiens un TABLE ACCESS FULL sur chaque requete utilisé pour l'operation MINUS.
Pour info NUM_OP est la clé de la table ENTETE_OP, et est aussi un index dans la table LIGNE_COLISEE
Si quelqu'un a une idée de la manière à proceder pour optimiser cette requete, qu'il le dise ou qu'il se taise à jamais !!!!

[McM]

1 minus fait déjà un distinct
1 IN (select ) : pas besoin de distinct

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SELECT *
FROM ENTETE_OP 
WHERE NUM_OP IN (
		SELECT NUM_OP 
		FROM LIGNE_COLISEE a
		WHERE (id_produit=039353 OR id_produit=636673 OR id_produit=636700 OR id_produit=637464)
		AND id_societe='PF'
		AND NOT EXISTS ( SELECT  1 
				FROM LIGNE_COLISEE  
				WHERE num_op  = a.num_op 
				AND id_produit <> 039353 AND id_produit <> 636673 
				AND id_produit <> 636700 AND id_produit <> 637464
				AND id_societe='PF'
				)
		)

et enfin avec des EXISTS et NOT EXISTS (tout dépend des index et de la taille de ta table principale)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SELECT *
FROM ENTETE_OP a 
WHERE EXISTS (	SELECT 1
		FROM LIGNE_COLISEE
		WHERE (id_produit=039353 OR id_produit=636673 OR id_produit=636700 OR id_produit=637464)
		AND id_societe='PF'
		AND num_op = a.num_op
		)
AND NOT EXISTS ( SELECT  1 
		FROM LIGNE_COLISEE  
		WHERE num_op  = a.num_op 
		AND id_produit <> 039353 AND id_produit <> 636673 
		AND id_produit <> 636700 AND id_produit <> 637464
		AND id_societe='PF'
		)

[elreybubu]

Merci beaucoup pour ta réponse,
Ta solution améliore légèrement le temps d'éxécution, mais il y a encore un table access full!!!
D'ou cela peut il venir?


Ps: Dans ton code tu ecrit, LIGNE_COLISEE a, il ne faut pas mettre le a

[McM]

Corrigé (un oubli lors du Copier-Coller)

Tu as aussi cette option la, que tu peux décliner avec un IN

Code :

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

1
2
3
4
5
6
7
8
WHERE EXISTS (
		SELECT 1
		FROM LIGNE_COLISEE
		WHERE id_societe='PF'
		AND num_op = a.num_op
		GROUP BY num_op
		HAVING MAX(DECODE(id_produit, 039353, 1, 636673, 1, 636700, 1, 637464, 1, 2)) = 1
		)

[elreybubu]

, mais quelle requete !!!!!!
En tout ca merci, elle marche très bien et je n'ai plus de table access full.
Le petit revers de la medaille c'est qu'elle a un cout de 1002 contre 110 pour ton ancienne proposition.
Alors ma derniere question sera la suivante :
Sur une base de prod, ou il risque d'y avoir plus de 500 000 lignes dan sla table LIGNES_COLISEE, quelle sera la moins couteuse?

[nuke_y]

Faut essayer

[elreybubu]

Faut essayer

Ca m'étonnerait que cette réponse satisfasse le client!!!!

Mais d'une manière générale, un table access full signifie que toutes les lignes sont parcourues, non? Donc plus il y a de lignes plus la durée d'execution est longue, non?

[McM]

Non, faut voir non pas le coût, mais le nb de lecture Blocks.
Après faut voir aussi les lectures multiblocks (lecture d'affilée, pas d'aller -retour) qui sont plus rapide.

Bref, sous TOAD, tu as l'option de l'AutoTrace qui te donne les "consistent gets"
La tu verras la meilleure requete, non pas en terme de durée, mais de qte de blocks lus.

[remi4444]

Attention, il faut bien comprendre que le cout est une estimation en fonction des stats. Les traces vont donner le résultat en terme d'IO réellement effectués. Si dans la première requête, oracle a choisi de faire un access FULL, c'est qu'il a estimé que c'était moins couteux, ce en quoi il s'est peut etre trompé pour le cas particulier de cette requête.

La 2ieme requête de mcm, lui force un autre plan d'exécution, c'est donc normal qu'à priori, il l'estime plus couteux que le premier (puisque c'est pas celui là qu'il avait pris quand il avait le choix), mais ça veux pas dire qu'il le soit... au contraire, s'il passe par les index, c'est rassurant à mon avis...