[ORACLE 8.1.7] Différence entre {SELECT a,b MINUS(UNION)} & {SELECT a,b NOT IN (AND)}

Bonjour,

J'explique ce titre un peu incompréhensible, je l'avoue.

J'ai d'une table sous ORACLE 8.1.7, je dispose aussi de plusieurs requêtes qui couvrent la majeure partie des enregistrements. Les requêtes sont distinctes entre elles, c'est à dire, qu'un enregistrement retourné par une requête n'est pas retourné par les autres.

Ce que je cherche à faire est de renvoyer les enregistrements non compris dans les requêtes prédéfinis.

L'idée est de faire une requête comprenant tous les enregistrements de la table et d'y retrancher les enregistrements pris en compte par les requêtes prédéfinis.

D'où les deus solutions suivantes :


1-

Code:

---

1 2	(SELECT * from Table1) MINUS ( R1 UNION R2 UNION R3 ...)

---

ou

2-

Code:

---

1 2	SELECT a,b from Table1 WHERE a,b NOT IN (R1 AND R2 AND R3 ...)

---

Questions :

I - Est ce que la syntaxe "2" est correcte?
II- Si oui, Laquelle des deux méthodes est la plus efficace en terme de temps de réponse?

Merci d'avance.

déjà remplace les UNION par UNION ALL.

Sinon : http://asktom.oracle.com/pls/ask/f?p...A:747025636772

Citation:

---

in theory, they would be the same - except minus has a sort distinct step
involved which not in does not, but if they were to be the same, then there must be a primary key involved so that might not even make a difference.

---

MINUS fait un tri qui peut être couteux... finalement, rien de mieux qu'un test ;)

Merci Fred_D, donc la solution I est equivalente à la solution II!

à noter que ce ne sont pas tout à fait les mêmes puisque si les 2 requêtes retourne NULL, la ligne sera supprimée dans le 1° cas mais pas dans le 2° il me semble.

Mais la 2° ne faisant pas de tri, elle devrait être meilleure :)

Je suis perplexe, ça dépend vraiment de ce que tu mets dans les R1, R2 etc... si ce sont des requêtes qui tapent dans les même tables, il est évident qu'il vaux mieux ne faire qu'un seul parcours avec plusieurs tests que plusieurs parcours avec un test chacun. Mais lorsque les requêtes devienent complexes, le minus parfois améliore les performances parcqu'il séparent les calculs de l'optimiseur en unités simples.

Pour résumer, je dirais que la 2ieme méthode est théoriquement plus éfficace mais que la 1iere est plus stable.

En fait, je pense que l'optimum n'est ni dans la 1ière ni dans la 2ieme mais dans une 3ieme qui utiliserait le "NOT EXISTS"... (et ce n'est pas que par esprit de contradiction...:p )

Utiliser "minus" peut s'avérer beaucoup plus performant qu'utiliser un "not in". Lorsque la clause in contient une sous-requête, celle-ci est recalculée plusieurs fois. Aussi :

select ...
...
where not in (select ... )

est beaucoup plus long que :

select ...
minus
select ...

Je viens de le vérifier sur un cas concret pour mon travail.

Evidemment, le NOT IN n'est pertinent que si la colonne qui sert à faire la jointure est indexée :)

Le MINUS est aussi bien utile lors d'utilisation de certaines tables en dblink et d'autre en local