JOIN sur de multiples conditions

[Djobird]

Bonjour,
voila supposons que j'ai les table suivantes:
Table A:
-id
-output
-input

Où output et input sont des clés étrangères sur la table:
Table B:
-id
-valeur
-type

Je voulais faire quelque chose du genre

Code :

SELECT A.output, A.input, B.valeur FROM A JOIN B ON (A.output=B.id OR A.input=B.id) WHERE B.type = blabla

Sauf que, comment je fais pour savoir à quelle donnée correspond B.valeur ? Est ce que ça va être celle de output, ou de input ?

Est ce que je peux faire ça avec un seul JOIN, ou je dois en utiliser 2, ou encore une sous requête ?

[dehorter olivier]

Sauf que, comment je fais pour savoir à quelle donnée correspond B.valeur ?

j'ai du mal à comprendre de sens de la question...

Est ce que ça va être celle de output, ou de input ?

par exemple ou utilisant un CASE

Code :

1
2
3
4
5
6
 
SELECT .....,
    CASE WHEN A.Input = B.Id THEN 'Input'
      ELSE 'Output'
    END
FROM .....

ou par un UNION
Mais quelle sera la plus rapide ??? à tester

[Djobird]

Je ne sais pas si j'ai compris ce que tu proposes, mais je crois que ca ne correspond pas à ce que je veux.

Supposons que j'ai les données suivantes

Table A:
-id : 1 2
-output : 1 1
-input : 2 3


Table B:
id : 1 2 3
valeur : a b c
type : g d b


Ce que je veux obtenir c'est quelque chose du genre

(A.id = 1, A.output=1, A.input=2, B.valeur=a, B.valeur=2)

Mais comment puis je savoir que B.valeur=a correspond a ouput, et que B.valeur=2 correspond a input ?

[Yanika_bzh]

Envoyé par Djobird

Je ne sais pas si j'ai compris ce que tu proposes, mais je crois que ca ne correspond pas à ce que je veux.

Supposons que j'ai les données suivantes

Table A:
-id : 1 2
-output : 1 1
-input : 2 3


Table B:
id : 1 2 3
valeur : a b c
type : g d b


Ce que je veux obtenir c'est quelque chose du genre

(A.id = 1, A.output=1, A.input=2, B.valeur=a, B.valeur=2)

Mais comment puis je savoir que B.valeur=a correspond a ouput, et que B.valeur=2 correspond a input ?

Je ne comprends rien a ce que vous essayez de nous expliquer

[CinePhil]

Il te faut deux jointures et non pas une jointure à double condition :

Code :

1
2
3
4
5
6
SELECT A.id, A.output, A.input
    B1.valeur AS valeur_output
    B2.valeur AS valeur_input
FROM A
INNER JOIN B B1 ON B1.id = A.output
INNER JOIN B B2 ON B2.id = A.input

[dehorter olivier]

Ce que je veux obtenir c'est quelque chose du genre

(A.id = 1, A.output=1, A.input=2, B.valeur=a, B.valeur=2)

ce n'est pas ce qui était écrit dans le premier message
pour rappel

SELECT A.output, A.input, B.valeur FROM A JOIN B ON (A.output=B.id OR A.input=B.id) WHERE B.type = blabla

cinephil a fourni la solution en tout cas à ta demande... mais peut-être pas à ton souhait

[Djobird]

Ce dont j'ai besoin est dans mon deuxieme message, à savoir:
(A.id = 1, A.output=1, A.input=2, B.valeur=a, B.valeur=b)

Je pensais que l'on pouvait obtenir ca avec une requete du genre celle que je proposais ...

Qu'est censer donner cette requete dans ce cas?

Code :

1
2
 
SELECT A.output, A.input, B.valeur FROM A JOIN B ON (A.output=B.id OR A.input=B.id) WHERE B.type = 2

Sinon merci bien CinePhil, c'est ce que je craignais, je vais devoir faire ca autrement :/ (je ne peux pas me permettre de faire une double jointure sur ces tables)

[CinePhil]

Envoyé par Djobird

(je ne peux pas me permettre de faire une double jointure sur ces tables)

Et pourquoi donc ?

[Djobird]

La table est assez grosse et cette requête sera exécutée trop souvent, la charge sera trop élevée pour la BD. De plus je ne l'ai pas précisé ici, mais table B devra être jointe elle aussi à chaque fois à une table C.
Un simple JOIN irait, mais 2 on craint que ça soit trop lourd. Mais bon on va tester ça quand même de tout façon.

[CinePhil]

Envoyé par Djobird

La table est assez grosse

Combien de millions de lignes ?

Mais bon on va tester ca quand meme de tout facon.

Deux jointures sur des entiers et sur des colonnes indexées, ça devrait passer sans problème jusqu'à plusieurs millions de lignes.

[iberserk]

Vos considérations sur les performances me paraissent bien subjective...

Correctement indexé il ne devrait pas y avoir de soucis...

[iberserk]

Pourriez vous exploiter une telle requête

Code :

1
2
3
4
5
6
7
8
9
10
11
12
 
SELECT A.id, A.output AS VALUE
    B.valeur,CAST(1 AS BIT) AS OUTPUT
FROM A
   INNER JOIN B 
      ON B.id = A.output
UNION
SELECT A.id, A.input AS VALUE
    B.valeur,CAST(0 AS BIT) AS OUTPUT
FROM A
   INNER JOIN B 
      ON B.id = A.input

[iberserk]

Code :

1
2
3
4
5
6
SELECT A.id, A.output, A.input
    B1.valeur AS valeur_output
    B2.valeur AS valeur_input
FROM A
INNER JOIN B B1 ON B1.id = A.output
INNER JOIN B B2 ON B2.id = A.input

Attention ici tout de même aux INNER JOIN qui excluraient les lignes pour lesquelles l'un des deux prédicat de jointure serait faux pour la ligne...

[CinePhil]

D'après ce que j'ai compris, output et input sont des clés étrangères donc elles ne devraient pas être à NULL et INNER JOIN devrait toujours fonctionner.

[iberserk]

D'après ce que j'ai compris, output et input sont des clés étrangères donc elles ne devraient pas être à NULL et INNER JOIN devrait toujours fonctionner.

Le fait qu'elles soient des clés étrangères ne conditionnent pas le fait qu'elle soit NOT NULL...

[CinePhil]

Envoyé par iberserk

Le fait qu'elles soient des clés étrangères ne conditionnent pas le fait qu'elle soit NOT NULL...

En bonne conception si !

[iberserk]

En bonne conception si !

Comment modélisez vous les relations 0-1?


En OLTP on est bien d'accord?

[CinePhil]

Envoyé par iberserk

Comment modélisez vous les relations 0-1?

Réponse dans mon blog !

Et je ne vois pas le rapport avec OLTP !

[iberserk]

Et je ne vois pas le rapport avec OLTP !

Et je vous comprends

Beaucoup de "spécialiste BI" utilise des clé à 0 dans les tables référencées pour justement éviter les NULL en FK... d'où ma remarque.

[Djobird]

La table en elle même ne devrait pas contenir des masses d'info, peut être 1 ou 2 millions.
Le probleme est que la table A va devoir être jointe deux fois à la table B qui contiendra à terme dans les 3 ou 4 millions de lignes, la table B devra être jointe 1 fois à une table C qu ia contenir aussi dans les 3 ou 4.
Puis la table A doit être jointe 2 fois à une table D, qui elle va contenir dans les 10 millions d'entré.
Bon hormis pour A, toutes les autres peuvent être indexé très simplement.
De plus il est possible qu'on dans les 40 requêtes par secondes pour ce query.
Peut être que tout va bien aller, je suis pessimiste.