Discussion :

[Vrylx]

Je travaille avec le SGBD Firebired 1.5, et j'ai des soucis avec une de mes requête qui met beaucoup beaucoup de temps à me renvoyer une réponse... Je précise que mes tables ne contiennent pas beaucoup de données pr le moment (10 à 30 insertions)...

voici le code :

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
 
SELECT DISTINCT 
AGENTS.NUMEROAGENTS FROM AGENTS ,AVOIRPERMIS ,ACQUIERT ,PASSE ,OBTIENT ,EXERCE ,DEMANDE ,ESTINDISPOHORAIRE  
WHERE 
((AVOIRPERMIS.NUMEROAGENTS=AGENTS.NUMEROAGENTS AND AVOIRPERMIS.NUMEROPERMIS=1) ) 
AND 
((ACQUIERT.NUMEROAGENTS=AGENTS.NUMEROAGENTS AND ACQUIERT.NUMEROQUALIFICATIONS=17) ) 
AND 
((PASSE.NUMEROAGENTS=AGENTS.NUMEROAGENTS AND PASSE.NUMEROCONCOURS=10) ) 
AND 
((OBTIENT.NUMEROAGENTS=AGENTS.NUMEROAGENTS AND OBTIENT.NUMERODIPLOMES=6) ) 
AND 
((EXERCE.NUMEROAGENTS=AGENTS.NUMEROAGENTS AND EXERCE.NUMEROGRADES=5) ) 
AND 
((DEMANDE.NUMEROAGENTS=AGENTS.NUMEROAGENTS AND DEMANDE.NUMEROSECTEURS=8) ) 
AND 
( AGENTS.NUMEROAGENTS NOT IN (SELECT ESTINDISPOHORAIRE.NUMEROAGENTS FROM ESTINDISPOHORAIRE WHERE ESTINDISPOHORAIRES.NUMEROAGENTS=AGENTS.NUMEROAGENTS AND ESTINDISPOHORAIRE.NUMEROHORAIRES=2) ) ;

Je suis prenant de toute solution ne me prenant pas plus de 5 min à attendre pour avoir un résultat de requête. Je cherche une requête équivalente à celle-ci mais plus optimisée... et je n'ai pas d'idée.. merci par avance de votre aide.

[Benjamin GAGNEUX]

A tu regardé dans les tutos IB ?

[Vrylx]

oui, mais jsais pas trop dans quel sens aller... c peut-être à cause du produit cartésien...

[Benjamin GAGNEUX]

As-tu mis des index sur toutes tes colonnes de recherches ?

[Vrylx]

oui. j'ai bien mis des index sur toutes mes colonnes.

[rsc]

Faire les jointures dans des JOIN au lieu de WHERE permettrait à mon avis à Firebird de mieux construire le plan de ta requête et donc d'accélérer le traitement.
Maintenant, lorsqu'on dépasse 4 ou 5 jointures, le ralentissement augmente très rapidement . Parmi les solutions envisageables :
- 2 requêtes successives avec une table intermédiaire
- l'utilisation de vues pour les parties de requête "en dur" (qui ne contiennent pas de paramètres)

[jean-jacques varvenne]

comme dit plus-haut, utilise join au lieu de where, et surtout, mais les plus petites tables en premier et dans la jointure, déclarer les plus petites tables à gauche, le gain peut dans certain cas être considérable.

une autre piste, est que tous les champs en relation soivent exactement du même type, il n'est pas rare de trouver dans des bases des champs de type char() et des varchar(), sans compter qu'un coup, il y a la contrainte not null et parfoit pas.

donc une règle simple, tous les champs doivent avoir la contrainte not null, être du même type pour la relation (même longueur pour les char/varchar) et si possible être en clé primaire.

si les tables deviennent "immenses" il est préférerable d'utiliser des champs numériques not null et en clé primaire dans les relations, le gain est spéctaculaire (plus d'un million d'enregistrements)