Discussion :

[freud]

Bonsoir à tous,

Voici 6 tables qui pourront être jointe par des PK et des FK dans une requête.
Tantôt on a besoin que de joindre TABLE1 et TABLE2 tantôt quatre tables ou les six tables. On extrait des informations de TABLE6 et peut-être qu'en même temps on a besoin d'une information de TABLE1 ou de TABLE2 enfin bref.
Ce que je souhaiterais savoir, c'est, afin de réduire le nombre de requête ne serait-il pas plus approprié d'élaborer une vue joignant les 6 tables ou même plus ? :

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
18
19
 
CREATE VIEW vwListe(
    CHAMP1,
    CHAMP2,
    CHAMP3,
    CHAMP4,
    CHAMP5,
    CHAMP6)
 
AS
 
SELECT T1.CHAMP1,T2.CHAMP2,T3.CHAMP3,T4.CHAMP4,T5.CHAMP5, T6.CHAMP6 FROM TABLE1 T1 
INNER JOIN TABLE2 T2 ON T1.CHAMP1=T2.CHAMP2
INNER JOIN TABLE3 T3 ON T2.CHAMP2=T3.CHAMP3
INNER JOIN TABLE4 T4 ON T3.CHAMP3=T4.CHAMP4
INNER JOIN TABLE5 T5 ON T4.CHAMP4=T5.CHAMP5
INNER JOIN TABLE6 T6 ON T5.CHAMP5=T6.CHAMP6
...................................................................
...................................................................

De laquelle on extrait les informations (et pas forçément toutes) au besoins :

Code :

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

1
2
 
SELECT CHAMP1,CHAMP2 FROM vwListe

au lieu de construire séparement :
Requete_1=SELECT CHAMP1,CHAMP2 FROM TABLE1 INNER JOIN TABLE2
Requete_2=SELECT CHAMP2,CHAMP3 FROM TABLE2 INNER JOIN TABLE3
Requete_n=....................................

Qu'en sera-t-il des performances si on fait appel tout le temps à cette vue au lieu de ces requêtes ?

Merci pour vos informations.

[makowski]

compare les plans et les stats de lecture de tes requêtes tu auras vite la réponse

qu'est ce qui est plus rapide pour chercher une bille bleue ?, chercher dans tous les sacs ou bien chercher seulement dans le sac des billes bleues ?

[freud]

Merci Makowski

Les plans ne sont pas les mêmes.......
et bien sûr que c'est dans le sac bleu mais ..........., pour me faire une idée, je voudrais m'assurer sur les indicateurs des stats à prendre en considération sous IB Expert :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
------ Performance info ------
Prepare time = 15ms
Execute time = 0ms
Avg fetch time = 0,00 ms
Current memory = 15 738 832
Max memory = 16 956 804
Memory buffers = 2 048
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 28

Je suppose que c'est le Prepare et l'Execute time ?
En terme de temps de préparation et de temps d'execution du plan de requête
pour le renvoi de l'ensemble des données ?

Merci.

[freud]

Bonsoir,

Je viens de trouver un thread :
http://www.developpez.net/forums/d96...e/#post5411543
traitant du même sujet que celui-ci. J'aimerais m'assurer que FB n'elimine pas les jointures inutiles
dans une vue afin d'abandonner cette methode.

J'ai fait deux tests sous IB Expert:

1) pour une vue jointant 4 tables et avec un SELECT CHAMP FROM LA VUE
ca donne comme stats :

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
 
Plan
PLAN JOIN (JOIN (JOIN (V_LIGNE_COMMANDE_CLIENT CD NATURAL, V_LIGNE_COMMANDE_CLIENT LC INDEX (FK_CDE_CLI)), V_LIGNE_COMMANDE_CLIENT LIGNE INDEX (PK_LIGNE)), V_LIGNE_COMMANDE_CLIENT AR INDEX (PK_ST_TB_ARTICLE))
 
Adapted Plan
PLAN JOIN (JOIN (JOIN (V_LIGNE_COMMANDE_CLIENT CD NATURAL, V_LIGNE_COMMANDE_CLIENT LC INDEX (FK_CDE_CLI)), V_LIGNE_COMMANDE_CLIENT LIGNE INDEX (PK_LIGNE)), V_LIGNE_COMMANDE_CLIENT AR INDEX (PK_ST_TB_ARTICLE))
 
------ Performance info ------
Prepare time = 0ms
Execute time = 0ms
Avg fetch time = 0,00 ms
Current memory = 9 573 220
Max memory = 10 081 336
Memory buffers = 2 048
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 39

2) pour un select jointant 3 tables et avec un SELECT CHAMP FROM LES TABLES ca donne comme stats :

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
 
Plan
PLAN JOIN (CD NATURAL, LC INDEX (FK_CDE_CLI), LIGNE INDEX (PK_LIGNE))
 
Adapted Plan
PLAN JOIN (CD NATURAL, LC INDEX (FK_CDE_CLI), LIGNE INDEX (PK_LIGNE))
 
------ Performance info ------
Prepare time = 0ms
Execute time = 0ms
Avg fetch time = 0,00 ms
Current memory = 9 566 820
Max memory = 10 081 336
Memory buffers = 2 048
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 28

Il me semble qu'il n' y a pas une grande différence entre les deux stats bien que les plans sont différents mais le problème c'est sans des données en production.

[makowski]

Avec la base employee il y a une vue PHONE_LIST qui lie les tables EMPLOYEE et DEPARTEMENT
un SELECT * from PHONE_LIST donne 42 lectures de EMPLOYEE et 21 de DEPARTEMENT
un SELECT EMP_NO FROM PHONE_LIST (donc en ne prenant qu'un champ de EMPLOYEE) idem

et c'est logique et cohérent

il faut bien respecter les demandes faites par les INNER JOIN que tu poses
explicitement, cela fait partie des contraintes de recherche que tu poses

ce n'est pas la même chose de dire que tu veux tous les enregistrement d'une table ou bien tous les enregistrement d'une table ayant une correspondance dans une seconde table.

[freud]

et c'est logique et cohérent

Oui c'est logique et cohérent. Dans les deux cas les plans ne bougent pas.
Maintenant c'est clair.
Merci à vous Makowski.