Requête ne prends pas en compte tous mes paramètres

**franoisiup** · 22/04/2009, 20h35

Bonsoir,
Ma requête de recherche de doublons fonctionne mais ne prends pas en compte les paramètres en rouge. Pourriez vous me dire pourquoi et comment je pourrais procéder pour qu'ils les prenne en compte.
En vous remerciant

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
Select 
AdresseP.NoPre AS NoPre,    
AdresseP.NomClas AS NomClas,    
AdresseP.NomPhon AS NomPhon,    
AdresseP.Prenom AS Prenom,
AdresseP.Serv AS Serv,        
AdresseP.Contact AS Contact,
AdresseP.NoVoie AS NoVoie,
AdresseP.LibVoie AS LibVoie,        
AdresseP.CPost AS CPost,    
AdresseP.Dep AS Dep,    
AdresseP.CPays AS CPays,    
AdresseP.Tel AS Tel,    
AdresseP.Fax AS Fax,    
AdresseP.Email AS Email,    
AdresseP.Adr1 AS Adr1,    
AdresseP.Adr2 AS Adr2,    
AdresseP.Adr3 AS Adr3,    
AdresseP.Adr4 AS Adr4,    
AdresseP.Adr5 AS Adr5,    
AdresseP.Adr6 AS Adr6,    
AdresseP.Adr7 AS Adr7
 
FROM AdresseP 
JOIN (
Select Tel,Fax from AdresseP
Group by Tel,Fax
Having count(*) > 1
       ) AS Dbl ON AdresseP.Fax = Dbl.Fax
 AND AdresseP.Tel = Dbl.Tel
 AND AdresseP.Fax IS NOT NULL
 AND AdresseP.Tel IS NOT NULL
ORDER BY Tel,Fax

**agemis31** · 22/04/2009, 20h59

Bonsoir,

NULL n'est pas une valeur.

Vous faites une jointure sur Fax et Tel

AS Dbl ON AdresseP.Fax = Dbl.Fax
AND AdresseP.Tel = Dbl.Tel

Vous comparez des valeurs, les nulls sont exclus

C'est le comportement habituel.

Il y a une option ANSI_NULLS dans SQL serveur qui modifie ce comportement

Code :

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

1
2
3
4
SET ANSI_NULLS ON -- ANSI
if null=null print 'ansi_nulls on'
SET ANSI_NULLS OFF
if null=null print 'ansi_nulls off'

@+

**franoisiup** · 22/04/2009, 21h10

Désolé mais je ne comprends votre réponse:

SET ANSI_NULLS ON -- ANSI
IF NULL=NULL print 'ansi_nulls on'
SET ANSI_NULLS OFF
IF NULL=NULL print 'ansi_nulls off'

Je ne comprends ce que cette instruction fait.

En faite ma requête recherche tous les doublons sur le TEL et le FAX en excluant tous les TEL nul (AND ADRESSEP.TEL IS NOT NULL) et tous les FAX nul (AND ADRESSEP.FAX IS NOT NULL)

**agemis31** · 22/04/2009, 21h32

Bonsoir,

L'aparté SQL Serveur, c'était pour illustrer le comportement des nulls, notamment dans une jointure.

Vous essayez d'éliminer les nulls dans la jointure, il faut le faire avant
(dans les deux select sur AdresseP), ou après (dans un where) suivant ce que vous voulez faire.

@+

**andr386** · 22/04/2009, 21h34

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
[...]
FROM AdresseP 
JOIN (
Select Tel,Fax from AdresseP
Group by Tel,Fax
Having count(*) > 1
       ) AS Dbl ON AdresseP.Fax = Dbl.Fax
 AND AdresseP.Tel = Dbl.Tel
 AND AdresseP.Fax IS NOT NULL
 AND AdresseP.Tel IS NOT NULL
ORDER BY Tel,Fax

C'est intéressant tu essaies de faire une jointure avec un select imbrique ...
Je n'ai jamais vu ça, et ça doit être diablement lent a l'exécution.

Si ce genre de code fonctionne d'habitude, a ma connaissance tu devrais au moins donner le nom alias de la table Dbl dans le select imbrique : Select Tel, Fax from AdresseP Dbl
Mais sincerement j'ai peut-etre rien compris, mais meme si ca marchait ca serait horrible, tu vas faire une requete supplementaire par ligne. Le seul moyen propre que je vois de faire ta requete c'est avec un LEFT JOIN. Quelque chose du style :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
```
1
2
3
 
FROM AdresseP A
LEFT JOIN AdresseP Dbl ON  A.Fax = Dbl.Fax
```
et ensuite les having et autre joyeusetés.

**franoisiup** · 22/04/2009, 21h44

Il me semble que quand on utilise un JOIN il est impossible d'utiliser un WHERE.

**andr386** · 23/04/2009, 01h52

Envoyé par franoisiup

Il me semble que quand on utilise un JOIN il est impossible d'utiliser un WHERE.

Salut franoisiup, je ne connais pas du tout SQL Server, et j'ai l'impression que je serais bien surpris ;-) Mais en tout cas en SQL92, Oracle, Postgresql, inforbase, Mysql un JOIN n'empeche pas du tout d'utiliser un WHERE. Il n'y a vraimment aucun probleme avec ca, le JOIN est juste une facon esthetique d'ecrire une condition qu'on pourait tout a fait mettre dans le WHERE (c'est la syntaxe recommandee en Oracle d'ailleur).

Sinon si je me rappelle bien NULL n'est pas une valeur mais est signficatif, c'est un etat d'absence de valeur. Par exemple dans Oracle il y a plusieurs type de NULL different. Et evidemment il est pertinent de verifier qu'un champs est bien NULL dans ce derniers cas. Mais encore plus dans une jointure externe (Left Join, Right join).

**Waldar** · 23/04/2009, 02h17

Envoyé par andr386

C'est intéressant tu essaies de faire une jointure avec un select imbrique ...
Je n'ai jamais vu ça, et ça doit être diablement lent a l'exécution.

L'ensemble de votre commentaire (pas seulement la partie citée) est une succession de bétises.
Ce qui me fait peur (pour vous) c'est que vous donnez l'impression de connaître quelques SGBD et que vous ne seriez donc pas débutant.

Une jointure avec un select imbriqué, c'est extrêmement courant.
Google : SQL inline view.

Si c'est courant, c'est justement parce que c'est performant.

On peut tout à fait aliaser l'intérieur d'un select imbriqué, mais dans cet exemple ce n'est pas nécessaire car il y a une seule table.
Il est obligatoire d'aliaser ce select en SQL Server, mais chez Oracle ce n'est pas une obligation (ça reste une bonne habitude à prendre).

Et non, ça ne va pas générer une requête supplémentaire par ligne.
Le moteur va calculer le résultat de la vue et faire la jointure dessus comme si c'était une autre table.

Envoyé par andr386

Mais sincerement j'ai peut-etre rien compris

C'est malheureusement la seule chose correct de ce post...

Quant au problème initial, le rouge a disparu avec l'application de la balise code.
Mais pour dédoublonner votre requête est plutôt bonne, les IS NOT NULL auraient pu être mis dans la sous-requête, et aliaser des colonnes par leur même nom est inutile :

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
SELECT 
    AP.NoPre,
    AP.NomClas,
    AP.NomPhon,
    AP.Prenom,
    AP.Serv,
    AP.Contact,
    AP.NoVoie,
    AP.LibVoie,
    AP.CPost,
    AP.Dep,
    AP.CPays,
    AP.Tel,
    AP.Fax,
    AP.Email,
    AP.Adr1,
    AP.Adr2,
    AP.Adr3,
    AP.Adr4,
    AP.Adr5,
    AP.Adr6,
    AP.Adr7
FROM
    AdresseP AS AP
    INNER JOIN
    (
    SELECT Tel, Fax
    FROM AdresseP
    WHERE Tel IS NOT NULL
    AND Fax IS NOT NULL
    GROUP BY Tel, Fax
    HAVING count(*) > 1
    ) AS Dbl
      ON Dbl.Tel = AP.Tel
    AND Dbl.Fax = AP.Fax
ORDER BY
    AP.Tel asc,
    AP.Fax asc

**andr386** · 23/04/2009, 19h07

Envoyé par Waldar

L'ensemble de votre commentaire (pas seulement la partie citée) est une succession de bétises.
Ce qui me fait peur (pour vous) c'est que vous donnez l'impression de connaître quelques SGBD et que vous ne seriez donc pas débutant.

Une jointure avec un select imbriqué, c'est extrêmement courant.
Google : SQL inline view.

Si c'est courant, c'est justement parce que c'est performant.

J'ai été voir sur Google et je suis surpris de voir qu'apparement les select imbriques "SQL inline view" sont même recommandes pour des questions de performances...

Je suis conscient que les select imbrique sont extrêmement courant, mais je pensais que c'était plutôt pour des questions de facilite d'écriture que de performances.

Je travaille principalement sous PostgreSQL et MySQL, et j'ai toujours eu
des gains de performances très important en transformant des selects imbriques en jointures. Quand j'optimise une requete qui va trop lentement je demande le schema d'execution de la requete (Explain) et je n'ai jamais vu de select imbriques qui soit aussi rapide ou optimise qu'une jointure.

Evidement je ne connais pas bien les autres moteurs de base de données dans leur version actuels (oracle, SQL server ...).

Les selects imbriques que j'ai rencontres jusqu'à présent on toujours été des facteurs de ralentissement conséquent attribuable a la fainéantise (simplicité, facilite) ou l'incompétence du développeur l'ayant écrite.

http://www.codersrevolution.com/inde...N-vs-subselect
http://www.mysqlperformanceblog.com/...s-performance/

**Waldar** · 23/04/2009, 22h29

Il y a une énorme différence entre :

Code :

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

1
2
3
select <monselect>
from <matable>
where <macolonne> <opérateur> ( <une sous requête> )

Et

Code :

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

1
2
3
select <monselect>
from <matable>
    <jointure> ( <une sous requête> )

Dans le code présenté par franoisiup, c'était déjà le second cas.

Apparement d'après votre second lien, MySQL 4.1 gère (très mal) les sous-requêtes dans le from. Ca ne choquera pas les habitués de ce forum

Requête ne prends pas en compte tous mes paramètres

Langage SQL

Discussions similaires

Partager

Partager