Discussion :

[j.lebowski]

Bonjour,

je dois développer une BDD avec Access pour gérer le transport de personnes. Cette BDD concerne les réservations et le planning et devra être mise sur un serveur.

bref.

voici mon problème : je cherche à afficher les informations concernant des trajets (excursions) et pour ce faire je dois exécuter des requêtes outer join (right et left). En fait mes requêtes fonctionnent mais l'affichage des infos met 30 secondes à se faire, or il faudrait pouvoir exécuter cette requête en un temps raisonnable de 1 seconde voire moins
Ma question est la suivante : est-ce que c'est un problème inhérent au type de requête (outer join) ou bien est-ce qu'il est possible que j'ai très mal optimisé mes requêtes , ce qui est possible puisque je n'ai pas pensé un instant à l'aspect temporel, croyant que de toute façon ça irait vite.

Je précise que je ne suis pas informaticien mais bon je connais malgré tout le SQL et l'UML, bien qu'Access ne respecte pas trop les règles UML.

Merci d'avance et j'espère à très bientôt

PS : je travaille avec Access 2007.
PPS : je donnerai bien sûr plus de précisions si vous me répondez que c'est ma façon de modéliser/créer les requêtes qui est en cause.

[Jean-Philippe André]

salut,

en terme d'optimisation, tu peux voir deja si tes tables ont bien des cles primaires qui permettent un index et des temps de reponse ameliores.

Ensuite, au niveau de la requete en elle-meme, on peut peut etre voir le SQL et proposer des pistes

[j.lebowski]

En fait mes tables ont toutes des clés primaires correctes je pense mais je crée une requête outer join sur des requêtes qui sont déjà des outer join de requêtes classiques (des sommes et une union). Est-ce possible de créer une table temporaire après la création d'une requête ? Comme ça je peux donner une clé à cette table et donc peut-être accélérer l'exécution non ?

Je ne sais pas trop ce qui est faisable à ce niveau, j'avais déjà fait un projet Access mais jamais de requête aussi complexe en terme de jointures. Cela dit elle fonctionne mais elle est longue à l'exécution.

[Jean-Philippe André]

Coller le resultat d'une requete dans une table tampon est interessant seulement si la requete en question n'est a lancer qu'une fois, pour y appliquer ensuite moultes filtres.

Code SQL :

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

SELECT ... INTO TabTemp FROM RequeteComplexe;

apres tu pourras lancer sur une table figee:

Code SQL :

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

SELECT ... FROM TabTemp;

[j.lebowski]

Et si je dois rafraichir la requête alors (donc la relancer plein de fois), c'est mort pour les tables tampon ?

[Jean-Philippe André]

ce n'est pas mort, mais j'en vois moins l'interet

[f-leb]

bonjour à tous,

@j.lebowski, regarde si tu n'es pas dans un de ces cas là à éviter: http://loufab.developpez.com/tutorie...sation/#LIII-E

[j.lebowski]

Bonjour,

merci de vos conseils. Pour l'instant la solution que j'ai trouvé (sic) c'est de réduire le nombre de requêtes à appeler. Du coup certaines requêtes (notamment avec jointures externes) sont appelées 1 ou 2 fois par jour seulement.

Il reste une requête qui met quand même quelques secondes à s'exécuter, je mets le code au cas où ça vous donne des idées :

Code SQL :

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

1
2
3
4
5
6
7
8
 
SELECT numero_excu, passagers
FROM total_sauf_longs
UNION
SELECT numero_excu, passagers
FROM total_long1
UNION select numero_excu, passagers
FROM total_long2;

EDIT : j'utilise maintenant UNION ALL, j'ai lu que c'était plus rapide et je le constate, cependant ça met encore 4 secondes environ, ça fait beaucoup dans le contexte d'utilisation de ce formulaire.

RE-EDIT : finalement je pense que je vais faire des tables supplémentaires ou bien mettre plus de types d'excursions différentes, comme l'héritage a l'air compliqué je vais faire plein de tables.

[f-leb]

Bonjour,

…je vais faire plein de table…

Et ainsi multiplier les appels récurrents à l’opérateur UNION …

Il y a d’autres manières de prendre en compte l’héritage. La plus évidente étant de généraliser ces types d’excursion et tout mettre dans la même table avec un champ supplémentaire TypeExcursion (plus besoin du pénalisant opérateur UNION pour rassembler toutes tes excursions).

Evidemment il faut étudier les conséquences, comme tu parles d’héritage "compliqué",
voir http://warin.developpez.com/tutoriel...onnees-access/

[j.lebowski]

C'est en fait ce que j'ai fait, j'ai mis un champ "type" mais j'évite au maximum les requêtes union. Dans mon cas ça se traduit par plusieurs formulaires au lieu d'un seul, c'est pas forcément gênant mais je vais voir ce que ça fait si je mets tout dans le même.

Merci en tous cas.