si on utilise des index ... est-ce plus performant de regrouper les conditions d'une meme table (dans la clause where) que de les mettre arbitrairement ?
Moi je pensais ke mettre un where du genre:
t1.c1=t2.c1 and t2.c2=t3.c2 and t1.c3=t2.c3
 
etait equilvalent a :
t1.c1=t2.c1 and t1.c3=t2.c3 and t2.c2=t3.c2

[edit]--Message édité par wouatouwouatou--[/edit]

Slt
Je pense pas qu'on puisse établir une règle générale à cer sujet. Tout dépend de l'optimiseur de reqs du SGBD que tu utilises

P.S. en fait, ta question n'est pas une question sql...

Désolé pour mes éluKubrations hors sujet ; le sujet s'set pas affiché correctement sur mon écran

Au contraire je pense que c'est valable pour tout SGBD...
En effet dans la deuxieeme proposition la condition trois est la seule a utiliser la table t3 donc ne pas l'evaluer fais gagner du temps or il n'y besoin de l'evaluer que si les deux premieres sont vraies...
Les conditions sont tres rarement optimisees a causes des differences et/ou...

la position relative des jointures et des conditions sur
un meme table a de l'importance, mais faut de l'expérience
pour savoir comment optimiser

 
Non.. non... C'est moi ki ai reédité le tôpic sur tes conseils...

 
Si j'ai bien compris, en fait, il fo regrouper par table alors ?
Les conditions s'effectuent séquentiellement ? Et si oui, même pour le 'OR' ?

[edit]--Message édité par wouatouwouatou--[/edit]

kel en sont les gains ? au nivo perfs.
gagne ton bcp?

Pas sûr.
Exemple :
Soient 3 tables : t1,t2,t3.
Les 3 tables contiennent une colonne maFK, une clé étrangère (indexée).
pour accéder aux 3 tables, il suffit d'écrire
where t2.maFK = t1.maFK
  and t3.maFK = t2.maFK
 
La clause additionnelle and t1.maFK = t3.maFK est redondante ; En sybase sql server, il est conseillé d'ajouter la 3e jointure dans la req, de sorte que l'optimiseur de reqs étudie tous les chemins et trouve une meilleure solution pour renvoyer le result set.

Salut
 
En règle générale,
SQL travaillant par balayage des tables, on doit mettre la condition la plus discrimante en premier et ainsi de suite
De plus l'utilisation de sous requêtes avant les jointures peut permettre de gagner un temps d'éxecution appréciable.
 
Mais tout ca tu l'a vu en Maitrise d'Info, les espèces d'arbres de requêtes ca te dit rien ?
 
a+

ouais.. bien sûr, bien sûr...Evidemment ke je l'ai vu!!!
Mais de loin... très loin... d'autant plus loin ke la salle etait grande D
 
kentends-tu par la plus discriminante? un chtit exemple pliz
 
Et est-ce ke ca change kkchose ke d'ecrire:
t1.c1=t2.c1
en
t2.c1=t1.c1 ?
 
 
thegti> toi ki est specialiste de sql.. tu pourrais pas vérifier ma requete de l'autre topic et me l'optimiser plzzzz
P.S: au fait, tu rentres a kel heure ce soir ?

[edit]--Message édité par wouatouwouatou--[/edit]

Discriminante = qui en enlève le plus
 
Exemple:
Qui est né le '25/05/1980' et joue au football professionnellement ?
 
SELECT P.NOM, P.PRENOM
FROM PERSONNE P, TRAVAIL T
WHERE P.IDPER=T.IDPER  
AND T.JOB='Football'
AND P.DATENAISSANCE='25/05/1980'
 
La c'est pas optimisé du tout
 
Y'a vachement plus de joueurs de foot que de personnes né le 25/05/1980
La condition T.JOB='Football' est moins discriminante que la condition P.DATENAISSANCE='25/05/1980'
Donc:
SELECT P.NOM, P.PRENOM
FROM PERSONNE P, TRAVAIL T
WHERE P.IDPER=T.IDPER  
AND P.DATENAISSANCE='25/05/1980'
AND T.JOB='Football'
 
De plus ca dépend aussi des indexs, si JOB est indexé et DATENAISSANCE pas alors la première solution peut être la plus rapide, mais ca dépend aussi du nombre de lignes
 
On peut même aller plus loin dans l'optimisation (en évitant les jointures initules)
SELECT P.NOM, P.PRENOM
FROM  
(SELECT P.IDPER, P.NOM, P.PRENOM
 FROM PERSONNE P
 WHERE P.DATENAISSANCE='25/05/1980') TMP1,
(SELECT T.IDPER
 FROM TRAVAIL T
 T.JOB='Football') TMP2
WHERE TMP1.IDPER=TMP2.IDPER  
Mais bon, là ca bouffe de la mémoire et c'est pas forcément plus rapide, car le SGBD gère assez bien la cohabitation entre les jointures et les conditions car il travaille sur les indexs (s'ils existent bien sûr)
 
De plus je me suis penché sur la question qu'en Access, un petit SGBD quoi, et je pense que SQLServer ou Oracle doit gérer certaines optimisations tout seul
 
a+

Dans Oracle, fais un "explain plan" sur ta requête tu pourra voir les causes de lenteur.

ouhla... C koi ke ce explain plan??
C ou ke je dois taper ca?
Moi jutilise toad... et sqlplus (l'interpreteur par defaut koi)
jai aussi sqlLab.. mais celui la, jsais encore moins lutiliser ke les deux autres

up

Je connais pas Oracle mais explain plan, ça doit être une commande qui permet d'obtenir le plan d'exécution de tes requêtes

C'est ilisible pour les débutants un explain plan ( même pour les confirmés, surtout quand y'a beaucoup de tables )
le mieux est de chercher en retouchant la requete et mesurant les temps de réponse à l'aide de set timing on. par expérience, je sais bien que les sgbd ne trouvent pas forcément la meilleure optimisation, ça c'est surtout vrai avec sql server ( 7.0 ).