Discussion :

[jflebegue]

Bonjour,

J'ai une question pour les plus expérimentés sur les SGBDR et les requètes SQL.
Lors d'une jointure entre 2 tables exemple: SELECT * FROM T1,T2 WHERE T1.ID=T2.ID
il semblerait que la perf dépende du nbre d'eregistrement dans les 2 tables T1 et T2 mais aussi et c'est moins intuitif d'une disymétrie du nombre d'enregistrements... je m'explique la table T1 200 lignes. La table T2 1500000 lignes.

J'ai eu a faire ou plutot à renoncer à ce genre de requète dans une telle situation sous Access2000 (je sais c'est pas un SGBDR, mais bon il s'en tire pas mal pour une utilisation monoposte et personnelle)

Avez vous un avis, une idée, une explication sur la question?
Merci.
JF

[orafrance]

et bien plus il y a de combinaison différente pour associer les enregistrements plus c'est lent... ça me parait logique non ?

[papounet]

Dépend de trois choses principales :
1 > Les différentes stratégies d'accés que le SGBD est capable de mettre en oeuvre.
2 > L' "INTELLIGENCE" de l'optimiseur déterminant la strategie d'accés aux données dans ce cas précis.
3 > La bonne indexation des tables

Pour le 1 et 2, il est sur qu'ACCESS n'est pas DB2 ou ORACLE
Pour le 3, c'est toi qui t'y colle

[Barbibulle]

Oui comme le dit orafrance ce n'est pas comme vous le dite la disymétrie du nombre d'enregistrement entre les deux tables qui influe sur les performances mais plutot le nombre de correspondance qu'il y a dans la grosse table pour un élément de la petite table.

En d'autre termes s'il y avait une correspondance 1 pour 1 (et donc il y aurait 1 499 800 enregistrements de la grosse table sans correspondances avec ceux de la petite table) votre requete serait immédiate (du moins elle devrait l'être).

Or votre problème c'est que pour un enregistrement de votre petite table il doit y avoir des dixaines ou centaines de millers d'enregistrements correspondant dans votre grosse table. Et donc le résultat de la jointure est ennorme.

Dans un SGBD client/serveur l'exécution de la requete est immédiate ce qui est long c'est de parcourir tout le résultat (fetch).

[jflebegue]

Je sais qu'il y a des requetes à favoriser pour obtenir le meilleur temps de réponse et j'avais compris suite à des retours d'expétriences que les fortes disymétries entre 2 tables étaient très couteuses.
Il est vrai et j'aurai pu y réfléchir que, par exemple, pour des requètes imbriqués, en général (vous me direz si je me trompe) on commence par mettre en premier
( celle qui se situe au bout du

Code :

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

1
2
SELECT IN( SELECT IN(... ici
))

)
la requête qui réduit le plus le nombre d'enregistrements retournés

Donc dans le cas précédent ca semble normal que ce soit le nombre de correspondances à créer et non la disymétrie qui soit couteuse.

A vérifier:
je vais faire un essai pour voir ce que cela peut donner:
Essai 1:
- dans une table 200 enregistrements avec dans l'autre table une correspondance de 7500 enregistrements
Essai 2:
- 200 enregistrements dont seul correspond avec 7500 enregistrements de la 2éme table
Essai 3:
- 200 enregistrements avec correspondance 1 pour 1 vers la 2ème table.

Je vais tester ca sous Access et je poste mes maigres conclusions
Merci
JF