Discussion :

[igorzup]

Bonjour,

je dois croiser deux tableau ayant deux caracteristiques identique...

et je ne vois plsu comment faire...

quelque un saurais?

genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
SELECT     dbo.F_COMPTET.CT_Intitule, dbo.F_COMPTET.CT_Siret, dbo.F_ECRITUREC.EC_Date, dbo.F_ECRITUREC.EC_RefPiece, dbo.F_ECRITUREC.EC_Intitule, 
                      dbo.F_ECRITUREC.EC_Montant, dbo.F_ECRITUREC.EC_Sens, dbo.F_ECRITUREC.EC_Lettrage
FROM         dbo.F_COMPTET LEFT OUTER JOIN
                      dbo.F_ECRITUREC ON dbo.F_COMPTET.CT_Num = dbo.F_ECRITUREC.CT_Num
WHERE     (dbo.F_ECRITUREC.EC_Sens IS NOT NULL) AND (dbo.F_ECRITUREC.EC_Lettrage AND F_ECRITUREC.CT_Num IN
                          (SELECT     F_ECRITUREC_1.EC_Lettrage, F_ECRITUREC_1.CT_Num
                            FROM          dbo.F_COMPTET AS F_COMPTET_1 LEFT OUTER JOIN
                                                   dbo.F_ECRITUREC AS F_ECRITUREC_1 ON F_COMPTET_1.CT_Num = F_ECRITUREC_1.CT_Num
                            WHERE      (F_COMPTET_1.CT_Num LIKE '41LM%') AND (F_ECRITUREC_1.EC_Sens IS NOT NULL) AND (F_ECRITUREC_1.EC_Lettrage <> '') AND 
                                                   (F_ECRITUREC_1.EC_RefPiece = '5260122846')))

regardez l'horreur que j'ai mise:
au niveau de la jointure, avant le "IN" j'ai deux conditions qui doivent se retrouver dans le select suivant...

merci d'avance

[pacmann]

Salut !

Bon, comme tu l'as deviné, j'ai un peu de mal avec le gros bloc...
Cela dit, le problème doit venir de :

Code :

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

1
2
3
 
AND (dbo.F_ECRITUREC.EC_Lettrage AND F_ECRITUREC.CT_Num IN
                          (SELECT     F_ECRITUREC_1.EC_Lettrage, F_ECRITUREC_1.CT_Num

Si tu veux l'existance 2 critères commun, en simplifiant, tu fais :

Code :

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

1
2
3
4
5
6
 
SELECT *
FROM TableA A
WHERE EXISTS (SELECT 1 FROM TableB B
                       WHERE A.col1 = B.col1
                           AND A.col2 = B.col2)

Deuxième remarque :
Si tu fais :

Code :

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

1
2
3
 
A LEFT OUTER JOIN B
WHERE B.col1 IS NOT NULL

Tu peux simplifier en enlevant "LEFT OUTER" et la condition de NOT NULL...

[igorzup]

trop fort ce pacman!

continue les pacgum!

(oups: merci!)

[igorzup]

regarde ma requete:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
SELECT     dbo.F_COMPTET.CT_Intitule, dbo.F_COMPTET.CT_Siret, dbo.F_ECRITUREC.EC_Date, dbo.F_ECRITUREC.EC_RefPiece, dbo.F_ECRITUREC.EC_Intitule, 
                      dbo.F_ECRITUREC.EC_Montant, dbo.F_ECRITUREC.EC_Sens, dbo.F_ECRITUREC.EC_Lettrage
FROM         dbo.F_COMPTET LEFT OUTER JOIN
                      dbo.F_ECRITUREC ON dbo.F_COMPTET.CT_Num = dbo.F_ECRITUREC.CT_Num
WHERE     EXISTS
                          (SELECT     F_ECRITUREC_1.EC_Lettrage, F_ECRITUREC_1.CT_Num
                            FROM          dbo.F_COMPTET AS F_COMPTET_1 LEFT OUTER JOIN
                                                   dbo.F_ECRITUREC AS F_ECRITUREC_1 ON F_COMPTET_1.CT_Num = F_ECRITUREC_1.CT_Num
                            WHERE      (F_COMPTET_1.CT_Num LIKE '41LM%') AND (F_ECRITUREC_1.EC_Sens IS NOT NULL) AND (F_ECRITUREC_1.EC_Lettrage <> '') AND 
                                                   (F_ECRITUREC_1.EC_RefPiece = '5260122846') AND (dbo.F_ECRITUREC.EC_Lettrage = F_ECRITUREC_1.EC_Lettrage) AND 
                                                   (F_ECRITUREC.CT_Num = F_ECRITUREC_1.CT_Num))

tu pense que je recupere que les lignes presentes dans les deux tables qui respectent les conditions?

[pacmann]

Je ne comprends pas très bien ta question...
Si la requête ne te renvoie pas ce que tu attends, je te propose de nous donner un exemple concret de ce que tu attends, et de ce que tu as reçu à la place...

Cela dit, quelques petits conseils :
- Donne des alias à tes tables : ça rend le code plus lisible (plus d'énormes préfixes pour les colonnes) et en plus, c'est indispensable quand tu utilises plusieurs fois la même table. (ce que tu as fait du coup dans la sous requête)
Ce n'est pas ce qu'il y a de plus "significatif", mais j'adore aliaser mes tables "a", "b", ... Mais je pense qu'on peut choisir un peu plus judicieusement les lettres

- Ce qui est important dans la sous-requête EXISTS, c'est le fait de trouver une ligne. "SELECT d.EC_Lettrage, d.CT_Num" risque juste de te tromper...
C'est pour ça que généralement on fait : SELECT 1
=> La partie déterminante est :

Code :

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

1
2
3
 
AND (b.EC_Lettrage = d.EC_Lettrage) 
AND (b.CT_Num = d.CT_Num))

NOTE Supplémentaire : On fait SELECT 1 et non SELECT *, parce que ça permet à ton SGBD de ne pas rechercher des données dont il n'a pas besoin

- Je réitère la remarque sur LEFT OUTER JOIN : ce n'est utile que lorsque tu cherches les lignes sans correspondance. Dans ton cas, c'est inutile...

Allez, ça donne donc :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
SELECT a.CT_Intitule, a.CT_Siret, b.EC_Date, b.EC_RefPiece, b.EC_Intitule, b.EC_Montant, b.EC_Sens, b.EC_Lettrage
FROM  dbo.F_COMPTET a JOIN dbo.F_ECRITUREC b
    ON a.CT_Num = b.CT_Num
WHERE  EXISTS
	(SELECT     1
	FROM  dbo.F_COMPTET AS c JOIN dbo.F_ECRITUREC AS d 
	  ON c.CT_Num = d.CT_Num
	WHERE      (c.CT_Num LIKE '41LM%') 
	  AND (d.EC_Sens IS NOT NULL) 
	  AND (d.EC_Lettrage <> '') 
	  AND (d.EC_RefPiece = '5260122846') 
	  AND (b.EC_Lettrage = d.EC_Lettrage) 
	  AND (b.CT_Num = d.CT_Num))

[fsmrel]

NOTE Supplémentaire : On fait SELECT 1 et non SELECT *, parce que ça permet à ton SGBD de ne pas rechercher des données dont il n'a pas besoin

Exceptionnellement, dans le cas de EXISTS, un SGBD normalement constitué considère SELECT * comme une décoration, histoire de simplifier le travail de l'analyseur syntaxique. Donc EXISTS (SELECT 1 ...) ou EXISTS (SELECT * ...) c'est du pareil au même. C'est déjà comme cela que les choses étaient vues avec DB2, en 1984...

[pacmann]

Très fort, fsmrel !

Ca casse un mythe...
J'ai essayé rapidement sur Oracle 9.2, et même le select de colonnes ne semble rien y changer (du moins dans le plan d'exécution).

Par contre, en quoi ça simplifie le travail de l'analyseur syntaxique ?

[igorzup]

grand merci a toi Mr Pacman!
Que les pacgums pleuvent devant toi!

merci aussi a fsmrel (j'ai rien compris a la précision, mais je laisse ca a l'avenir)

juste pour etre certain:
les deux tables sont issues de requetes sensiblement identiques.
je veux sortir de la deuxieme les lignes qui ont les couples CT_Num et CT_lettrage qui ne sont pas present dans la premiere

[fsmrel]

Ca casse un mythe...
J'ai essayé rapidement sur Oracle 9.2, et même le select de colonnes ne semble rien y changer (du moins dans le plan d'exécution).

Par contre, en quoi ça simplifie le travail de l'analyseur syntaxique ?

Supposez qu'on vous demande de concevoir un parser SQL.
Si vous autorisez que l'on puisse coder "SELECT FROM..." sans rien entre SELECT et FROM, vous serez obligé de passer en paramètre au bloc de contrôle qui va bien qu'il y a un EXISTS ou autre qui traîne en amont. C'est jouable, mais ça peut aussi poser des problèmes d'organisation de la grammaire, donc autant simplifier, ramener le tout à une situation connue, c'est-à-dire mettre un mickey pour séparer les termes SELECT et FROM. Pourquoi pas un astérisque ? cela suffit largement.

Le mieux serait de poser la question au père de SQL, Donald Chamberlin.

Je pense que SQLpro a aussi une opinion à ce sujet.

[Waldar]

Tom Kytes utilise WHERE EXISTS (SELECT NULL FROM...), justement pour insister sur le fait que le contenu du select n'est aucunement exploité.

[pacmann]

Ok fsmrel, c'est donc ça...

Ecrit tel quel, on pourrait voir EXISTS comme un opérateur booléen sur une relation. Et en tant que tel, la syntaxe SELECT xxx FROM ... est tout à fait justifiée, je trouve.
En fait, si on pouvait autoriser puis étendre la sélection sur table_dee, qui selon vos propos se ferait par :

Code :

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

1
2
3
 
SELECT
FROM;

Alors on pourrait étendre les règles de l'analyseur syntaxique à

Code :

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

1
2
3
 
SELECT 
FROM TaTable;

Et donc considérer qu'on peut avoir une projection vide d'un ensemble de lignes non vide... (c'est peut être des énormes conneries, mais bon)

Et, toujours dans ce mode de pensée, considérer le fait que xxx ne joue aucun rôle simplement comme un artifice d'optimisation du SGBD.

Cela dit, comme l'opération est vraiment particulière, on pourrait envisager de la définir directement comme un opérateur relationnel de "semi-jointure".
(Je ne tire pas l'idée du chapeau, mais j'y pense parce qu'Oracle et certainements d'autres donnent ce nom à l'opération réalisée sur EXISTS)

Code :

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

1
2
3
4
 
SELECT ...
FROM A SEMI JOIN B
  ON ...

... et définir cette opération comme la projection sur A de la jointure entre A et B. Ce qui, bien entendu, ne serait pas calculé de cette manière par le SGBD.

[fsmrel]

En fait, si on pouvait autoriser puis étendre la sélection sur table_dee, qui selon vos propos se ferait par :

Code sql :

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

1
2
SELECT
FROM;

Alors on pourrait étendre les règles de l'analyseur syntaxique à

Code sql :

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

1
2
SELECT 
FROM TaTable;

Et donc considérer qu'on peut avoir une projection vide d'un ensemble de lignes non vide... (c'est peut être des énormes conneries, mais bon)

Je vois que vous n’avez pas oublié l’existence des inséparables Table_Dee et Table_Dum (cf. le message auquel vous faites allusion).

Du point de vue de la théorie relationnelle, Table_Dee et Table_Dum sont des relations de degré 0. Table_Dee contient un seul tuple, à savoir le 0-tuple, tandis que Table_Dum ne contient aucun tuple.
Si j’utilise le langage Tutorial D, la projection de la relation TaTable sur les attributs X, Y, ..., Z s’écrit ainsi :

TaTable {X, Y, ..., Z}

Et selon la théorie relationnelle, il est parfaitement légal et légitime de formuler ainsi l’équivalent de votre requête :

TaTable {} ;

Date et Darwen appellent cette projection la nullary projection.
Si la relation TaTable est vide de tuples, la relation obtenue par cette projection est vide elle aussi, et il s’agit alors de Table_Dum, sinon la relation obtenue est Table_Dee.
Si TaTable n’est pas vide et que l’on cherche un résultat vide, alors on écrira par exemple — WHERE étant l’opérateur de restriction :

(TaTable WHERE false) {} ;

Cela dit, comme l'opération est vraiment particulière, on pourrait envisager de la définir directement comme un opérateur relationnel de "semi-jointure".
(Je ne tire pas l'idée du chapeau, mais j'y pense parce qu'Oracle et certainement d'autres donnent ce nom à l'opération réalisée sur EXISTS)

Je conviens. Confidence pour confidence, dans mon message en référence, l’expression "SELECT FROM ;" n’est pas de moi mais de Darwen, même chose pour les expressions ";" et "SELECT FROM WHERE false ;" (cf. "The Nullogist in Relationland" (C. J. Date & H. Darwen. Relational Database Writings 1989-1991 (Reading, Mass.: Addison-Wesley, 1992)).

[SQLpro]

Je pense que SQLpro a aussi une opinion à ce sujet.

Oui, effectivement en générale le SELECT * dans le exists est détecté comme "je m'en fou" par l'analyseur syntaxique. Mais ce n'est pas le cas du SELECT 1...
En effet, s'il y a aggrégation dans la sous requête comme dans le cas ci dessous :

Code :

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

1
2
3
4
5
6
SELECT ...
FROM   ...
WHERE  EXISTS(SELECT *
              FROM   
              GROUP  BY Col1
              HAVING COUNT(*) > 1)

ALors cette syntaxe sera fausse car le * empêche le groupage. Tant erst si bien que dans ce cas particulier on est obligé d'écrire :

Code :

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

1
2
3
4
5
6
SELECT ...
FROM   ...
WHERE  EXISTS(SELECT 1
              FROM   
              GROUP  BY Col1
              HAVING COUNT(*) > 1)

Par exemple.
Dès lors, en présence d'une constante ou d'une colonne nommée, l'analyseur n'agit pas tout à fait de la même façon et le plan est calculé différemment. Mais c'est essentiellement dû à l'aggrégation.
Mieux vaut donc mettre systématiquement le SELECT * lorsqu'il n'y a pas d'agrégat et le SELECT 1 lorsqu'il y en as un.
Pour ma part je trouverais plus sympa dans ce cas de mettre :

Code :

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

1
2
3
4
5
6
SELECT ...
FROM   ...
WHERE  EXISTS(SELECT NULL
              FROM   
              GROUP  BY Col1
              HAVING COUNT(*) > 1)

Car comme chacun devrait le savoir... NULL existe !

A +

[pacmann]

Dès lors, en présence d'une constante ou d'une colonne nommée, l'analyseur n'agit pas tout à fait de la même façon et le plan est calculé différemment.

C'est peut être chaud... mais on peut avoir un exemple où le calcul du plan d'exécution serait différent ? (et surtout montrer en quoi cela diffère)

@fsmrel : toujours riche en poésie et en références... ça fait plaisir
Si on m'enfermait dans un endroit avec pour seule occupation la lecture, ce seraient sûrement des livres sur la théorie relationnelle que je voudrais lire !
(Ou peut être plus directement sur la théorie des ensemble, tiens)

[fsmrel]

Si on m'enfermait dans un endroit avec pour seule occupation la lecture, ce seraient sûrement des livres sur la théorie relationnelle que je voudrais lire !
(Ou peut être plus directement sur la théorie des ensemble, tiens)

Je vous conseille les Principia Mathematica de Whitehead et Russel. Ça parle des classes (mais pas de leur lutte), de relations, et pas seulement 1 à 1, c'est torride...

[fsmrel]

Car comme chacun devrait le savoir... NULL existe !

Tout comme le Père Noël.

Le bonhomme NULL vit dans le Sorry Query Land, mais il est interdit de séjour dans le Relationland (cf. Date & Darwen). Darwen nous met en garde : une table peut attraper des nulls comme nous pouvons attraper des furoncles et autres pustules, donc autant se prémunir. C’est ce qu’il écrit dans "Into the Unknown" (cf. C. J. Date with a special contribution by Andrew Warden. Relational Database Writings 1985-1989 (Reading, Mass.: Addison-Wesley, 1990).

Cela dit, si NULL existe, il est instance d'une classe (ou type) forcément non vide. Laquelle ? La classe BOOLEAN ? Je sais que dans le Sorry Query Land on ose tout (c'est du reste à cela qu'on le reconnaît, comme dirait Fernand Naudin), quitte à polluer le type BOOLEAN. Ah ! Si George Boole voyait ça...

La pensée du jour (anonyme) :

"Il n'y a pas de troisième voie : il y a la bonne et la mauvaise".