optimisation de tables liées et fonction de regroupement
2 réponses
Freegate
Bonjour,
J'utilise Access 2002 avec un fichier de donnée sur le serveur et une base
programme sur chaque poste de travail.
Mon souci est que je rencontre des pb de lenteur de réponses à des requètes
lorsque que je consulte des tables distances par rapport à des tables
locales.
Après analyse de mon code source, j'ai constaté que j'utilisais beaucoup les
fonction de regroupement du type "dlookup", "dcount", "dsum".
Ma question est la suivante est-ce que utiliser le couple "DAO - recordset "
dans mon code serait de nature à améliorer les temps de réponse. ? Si oui
dans quelle proportion (serait-ce vraiment significatif) ? et qu'est-ce qui
expliquerait que les fonctions de regroupement soient plus lentes ?
Je ne vous cacherais pas que je préfére utiliser les fonctions de
regroupement, car celles-ci sont plus faciles à programmer et devoir
manipuler des recordset, ça n'est pas évident.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3stone
Salut,
"Freegate" | J'utilise Access 2002 avec un fichier de donnée sur le serveur et une base | programme sur chaque poste de travail. | | Mon souci est que je rencontre des pb de lenteur de réponses à des requètes | lorsque que je consulte des tables distances par rapport à des tables | locales.
Pour un système "serveur de fichiers" le réseau sera toujours le point faible. Mais, le premier problème est le fait que si l'on fait n'importe quoi en local on ne s'en rend pas (toujours) compte... La même méthode se retrouvant sur le réseau, on remarque cela pompe péniblement.
| Après analyse de mon code source, j'ai constaté que j'utilisais beaucoup les | fonction de regroupement du type "dlookup", "dcount", "dsum".
Autant que possible, ouvrir en lecteure seule (type instantané) Un Dlookup est suberbe de simplicité lorsqu'il faut récupérer un valeur, mais appelé à chaque "ligne" d'une requête de quelques milliers ou dizaine de milliers d'enregistrements... A ce niveau, les champs indexés sont d'une importance vitale !!!
On peut aussi envisager de rapatrier le minimum de données dans une table locale temporaire et de finaliser ensuite...
| Ma question est la suivante est-ce que utiliser le couple "DAO - recordset " | dans mon code serait de nature à améliorer les temps de réponse. ? Si oui | dans quelle proportion (serait-ce vraiment significatif) ? et qu'est-ce qui | expliquerait que les fonctions de regroupement soient plus lentes ?
Il n'y a pas de généralité. Tout est une question de besoins... Ouvrir et fermer un recordset à chaque 'ligne' n'est pas plus performant qu'un DMax (une indexation bien pensée serait plus profitable) Ne pas faire de Select table.* dès que la table contient des champs non strictement nécessaires.. Ne pas utiliser de recordset dynamique s'il n'est question que de sélection.
| Je ne vous cacherais pas que je préfére utiliser les fonctions de | regroupement, car celles-ci sont plus faciles à programmer et devoir | manipuler des recordset, ça n'est pas évident.
"Freegate"
| J'utilise Access 2002 avec un fichier de donnée sur le serveur et une base
| programme sur chaque poste de travail.
|
| Mon souci est que je rencontre des pb de lenteur de réponses à des requètes
| lorsque que je consulte des tables distances par rapport à des tables
| locales.
Pour un système "serveur de fichiers" le réseau sera toujours le point faible.
Mais, le premier problème est le fait que si l'on fait n'importe quoi en local
on ne s'en rend pas (toujours) compte...
La même méthode se retrouvant sur le réseau, on remarque cela pompe péniblement.
| Après analyse de mon code source, j'ai constaté que j'utilisais beaucoup les
| fonction de regroupement du type "dlookup", "dcount", "dsum".
Autant que possible, ouvrir en lecteure seule (type instantané)
Un Dlookup est suberbe de simplicité lorsqu'il faut récupérer un valeur,
mais appelé à chaque "ligne" d'une requête de quelques milliers ou dizaine
de milliers d'enregistrements...
A ce niveau, les champs indexés sont d'une importance vitale !!!
On peut aussi envisager de rapatrier le minimum de données dans
une table locale temporaire et de finaliser ensuite...
| Ma question est la suivante est-ce que utiliser le couple "DAO - recordset "
| dans mon code serait de nature à améliorer les temps de réponse. ? Si oui
| dans quelle proportion (serait-ce vraiment significatif) ? et qu'est-ce qui
| expliquerait que les fonctions de regroupement soient plus lentes ?
Il n'y a pas de généralité. Tout est une question de besoins...
Ouvrir et fermer un recordset à chaque 'ligne' n'est pas plus performant
qu'un DMax (une indexation bien pensée serait plus profitable)
Ne pas faire de Select table.* dès que la table contient des champs
non strictement nécessaires..
Ne pas utiliser de recordset dynamique s'il n'est question que de sélection.
| Je ne vous cacherais pas que je préfére utiliser les fonctions de
| regroupement, car celles-ci sont plus faciles à programmer et devoir
| manipuler des recordset, ça n'est pas évident.
"Freegate" | J'utilise Access 2002 avec un fichier de donnée sur le serveur et une base | programme sur chaque poste de travail. | | Mon souci est que je rencontre des pb de lenteur de réponses à des requètes | lorsque que je consulte des tables distances par rapport à des tables | locales.
Pour un système "serveur de fichiers" le réseau sera toujours le point faible. Mais, le premier problème est le fait que si l'on fait n'importe quoi en local on ne s'en rend pas (toujours) compte... La même méthode se retrouvant sur le réseau, on remarque cela pompe péniblement.
| Après analyse de mon code source, j'ai constaté que j'utilisais beaucoup les | fonction de regroupement du type "dlookup", "dcount", "dsum".
Autant que possible, ouvrir en lecteure seule (type instantané) Un Dlookup est suberbe de simplicité lorsqu'il faut récupérer un valeur, mais appelé à chaque "ligne" d'une requête de quelques milliers ou dizaine de milliers d'enregistrements... A ce niveau, les champs indexés sont d'une importance vitale !!!
On peut aussi envisager de rapatrier le minimum de données dans une table locale temporaire et de finaliser ensuite...
| Ma question est la suivante est-ce que utiliser le couple "DAO - recordset " | dans mon code serait de nature à améliorer les temps de réponse. ? Si oui | dans quelle proportion (serait-ce vraiment significatif) ? et qu'est-ce qui | expliquerait que les fonctions de regroupement soient plus lentes ?
Il n'y a pas de généralité. Tout est une question de besoins... Ouvrir et fermer un recordset à chaque 'ligne' n'est pas plus performant qu'un DMax (une indexation bien pensée serait plus profitable) Ne pas faire de Select table.* dès que la table contient des champs non strictement nécessaires.. Ne pas utiliser de recordset dynamique s'il n'est question que de sélection.
| Je ne vous cacherais pas que je préfére utiliser les fonctions de | regroupement, car celles-ci sont plus faciles à programmer et devoir | manipuler des recordset, ça n'est pas évident.
"3stone" a écrit dans le message de news: | Salut, | || A ce niveau, les champs indexés sont d'une importance vitale !!! | |
Merci pour l'info, je vais me pencher sur les indexations alors !!!
"3stone" <3stone_@_skynet_be> a écrit dans le message de
news:ulOB1ZZKGHA.3936@TK2MSFTNGP12.phx.gbl...
| Salut,
|
|| A ce niveau, les champs indexés sont d'une importance vitale !!!
|
|
Merci pour l'info, je vais me pencher sur les indexations alors !!!
