Bonsoir
 
je fais une requete sql sous acces ou je veux trouver les produits en stock non existant dans un fichier d'article
 
voila la requete que j'ai ecrite
 
SELECT stock2.Code_alpha, stock2.[date-saisie], stock2.quantité
FROM stock2
WHERE (stock2.[Code_alpha] not   in
 ( SELECT article_base.Code_alpha
FROM article_base  );
 
La requete ... IN    remonte 5287 enreg  sur les 5575 du fichier stock
 et la requete NOT in    remonte 0 !!!
 
 
Qui peux m'aider ou me donner une piste  
 
MERCI d'avance

not exists plutot si il n'existent pas

edit ou mieux
SELECT stock2.Code_alpha, stock2.[date-saisie], stock2.quantité
from stock2 left join article_base on article_base.Code_alpha  = stock2.[Code_alpha]
WHERE  article_base.Code_alpha IS NULL
ce sera largement plus performant

Si "in" remonte 5287 enregistrements "not in" devrait en remonter  5575 - 5287. C'est bizzare.  
 
<troll>
Essai avec un vrai SGDBR tel que MySQL ou PostgreSQL et pas cette contrefaçon qu'est Access.
</troll>
 
PS: Dsl pour le troll c'était plus fort que moi.

j'avais meme pas vu qeu c'etait du access

SELECT stock2.Code_alpha, stock2.[date-saisie], stock2.quantité
FROM stock2 a
LEFT JOIN article_base b on b.Code_alpha = a.Code_alpha
WHERE b.Code_alpha is null

C'est sûr qu'on peut difficilement assimiler Access à un SGBD

 
Pas forcement, (null) n'est pas traité de la même façon dans tout les SGBD.

Ca me faire bizarre la left join avec un is null sur la condition de jointure...
 
 
A tester, basé sur sa version de la requête :

SELECT
    stock2.Code_alpha,
    stock2.[date-saisie],
    stock2.quantité 
FROM
    stock2 
WHERE
    stock2.[Code_alpha] NOT IN ( 
        SELECT
            article_base.Code_alpha 
        FROM article_base
    ) OR
   stock2.[Code_alpha) IS NULL
;

 
Sinon plus simple, je dirais :

SELECT
    stock2.Code_alpha,
    stock2.[date-saisie],
    stock2.quantité 
FROM
    stock2 
WHERE
    NOT EXISTS ( 
        SELECT
            1
        FROM
            article_base
        WHERE
            article_base.[Code_alpha] = stock2.[Code_alpha]
    )
;

 
Et pour modérer ce que disais Flo850, on s'en fou de faire une requête toute belle plein de jointure ou non, le but c'est d'avoir du SQL compréhensible à la lecture, et les optimisations des SGBD vont (quasi-toujours) convertir les in en where et les exists en jointure d'eux-même.

Les JOIN sont le standard et probablement toujours plus lisible que l'equivalent utilisant un sous select.
L'optimisateur arrive a la meme conclusion dans les deux cas mais ce n'est pas forcement garantis pour tout les SGBD.
Optimiser une query avec un sous select a la place d'un join prends un peut plus de temps aussi, et des fois ca fait la difference entre un bon query plan et un mauvais.
 
En regle generale il faut eviter les not exists et les not in, ca ouvre la porte a pleins de problemes si on ne fais attention.
 
La "beauté" du code a son importance, une requete avec un JOIN (ou left join + is null) est toujours plus compacte, et donc plus lisible qu'une query de 2km de long (15lignes vs 4 quand meme).
Des fois avoir un code compact (sans exagerer) est bien plus pratique que d'avoir de l'indentation et des retour a la ligne intempestif.
 
Au passage désolé a flo850 d'avoir repondu la meme chose que toi, j'avais pas vu que t'avais déja repondu ca

Ce n'est pas parce que c'est le "standard" (ouai à voir ce qu'on appelle le standard) que c'est plus compéhensible.
 
C'est quand même plus naturel à la compréhension de lire une requête avec des in/exists qui on plus de sémantique que des simple join. (et là on reste dans le SQL standard, si tu sort du SQL avec les jointures proprio Oracle c'est carrément à gerber...)

perso, je préfère largement les jointures
je trouve ça plus lisible

Sauf que sémantiquement c'est plus difficile de comprendre ce qu'il va se passer, et qu'en plus en fait en pratique ça peut être moins perfs :
http://explainextended.com/2009/09 [...] ql-server/
 
EDIT : De ce que j'ai lu, c'est le comportement décris est aussi valable pour Oracle.

Je cherche à associer tous mes élements de ma table gauche à ceux qui correspondent dans ma table  de droite (en utilisant telle et telle colonne pour faire le rapprochement )  
 
et en fait, je veux ceux qui n'ont rien à droite
 
Ca me semble plutôt compréhensible

 
C'est peut etre moins comprehensible pour toi, ca depend de l'habitude que tu as avec SQL. Perso je fais du SQL toute la journée et le temps de comprehension d'une query depend uniquement de la taille, donc plus c'est petit (sans etre compacté a outrance), plus c'est facil a comprendre et a lire.
Ce n'est peut etre pas evident avec des petites queries, mais des que tu as plusieurs tables ou tu dois melanger les JOIN et LEFT JOIN pour inclure et exclure des resultats ca devient tres tres vite illisible avec des NOT IN ou NOT EXISTS, surtout si on dois modifier une query existante pour juste enlever certains resultats (table d'exception, etc ...), on ajoute 2 lignes max avec un LEFT JOIN/ IS NULL.
Ca fait aussi une difference enorme pour la maintenance, en general tout est sur la meme ligne que le LEFT JOIN, il n'y a pas de parentese partout, pas plusieurs fois le mot select ni le mot where. Dans les grosses query ca fait la difference entre une query ou on en arrive a se perdre et une query qui tient sur 10 lignes et qui est comprehensible en un coup d'oeuil.
 
La question des perfs est tout a fait valide, mais comme pour toute question de perf ce n'est a utiliser que dans les cas ou c'est utile.