 1 membre
Connectés : ( personne )
 - La Charte du Forum - Forum
 - Questions générale
 Sujet n° 371 |
Fractionnement |
le 30/05/2010 : 13:59
par Kolele
visiteur
|
Salut à tous,
je commence à vouloir partager mes applications et je viens de découvrir le fractionnement des bases (avec les tables sur un partage réseau et les autres objets sur la Base de chacun des utilisateurs). Problème : ça ralentit un max, alors que la base initiale ne faisait que 12 Mo (la base principale en fait maintenant 11,8 et les bases utilisateurs 1,2 Mo) et que le test ne comporte que deux utilisateurs !
Enregistrer les données prend 55 secondes contre 3 auparavant !
le compactage n'a rien arrangé. Je potasse les index, truc dont je ne me suis jamais servi jusque là.
L'équipe du père 3Stone aurait-elle une piste ?! |
|  
|
Réponse n° 1
--------
le 30/05/2010 : 14:22
par Kolele
visiteur
|
Oublié de dire que je travaille sur ACCESS 2002 |
|
|
|
Réponse n° 2
--------
le 30/05/2010 : 19:09
par 3Stone
Administrateur
|
Bonjour,
Citation :Problème : ça ralentit un max
A part le fait qu'en DAO, Access est serveur de fichier, on peut dire que de placer une base (scindée) sur le réseau emplifie toutes les erreurs ou mauvaises méthode utilisée!
Par exemple, lorsque en local, on accroche une grosse table à un formulaire et que l'on utilise un simple filtre, cela ne se remarque quasiment pas. Toutes les données sont de toutes façon présentes.
La même méthode utilisée sur une base partagée sur un réseau freine des quatres roues 
L'explication est simple: toute la table doit transiter par le réseau, puisque le filtre ne s'applique que sur le poste qui reçoit!
Il ne faut donc utiliser un filtre qu'à la condition que les données soient déjà en local, pour les autres cas, il faut utiliser une requête avec une clause "Where".
Un autre, parmi de multiples points, sont les index. Les champs qui sont utilisés dans une clause Where ou dans les tri se doivent d'êtrent indexé.
L'absence d'index "en local" ne se fait pas beaucoup sentir... en réseau cette même absence est catastrophique en temps d'exécution.
Citation :Enregistrer les données prend 55 secondes contre 3 auparavant !
"Enregistrer les données" me fait penser à Word ou Excel
On ne sauve que la saisie ou la modification d'un seul enregistrement, c'est donc, en principe, instantané!
En fait, scinder la base et la placer sur le réseau, mets principalement le doigt sur toutes les mauvaises méthodes et mauvaises "constructions". Corriger tous ces manquements peut, dans les cas extrêmes... conduire à tout recommencer.
Cordialement,
Pierre(3stone) |
|
|
|
Réponse n° 3
--------
le 30/05/2010 : 20:45
par Kolele
visiteur
|
Merci pour tes explications très pédagogiques, Pierre. Je vais méditer tout ça.
Je commence à comprendre : les tables sont sur le réseau, requetes form et états sont chez l'utilisateur. Donc, il faut ne faire appel qu'aux données strictement nécessaires. Et le filtre c'est au niveau de la requete ; si je ne mets aucune condition dans la sélection, toutes les données descendent.
Je pensais avoir acquis de la méthode, mais ces 55 secondes me prouvent le contraire ! Et je suis encore un peu bleu en SQL.
à plus,
kolele |
|
|
|
Réponse n° 4
--------
le 31/05/2010 : 00:02
par Kolele
visiteur
|
Maître 3Pierre,
J'ai relu tes fondamentaux sur la normalisation. Les formes
de normalisation sont plutôt bien respectées au niveau de la conception de mes
tables et de leurs relations entre elles.
A une exception près : je pompe les données Elèves (je bosse
dans un lycée) dans une base maison (Sconet, qui contient les noms Elèves, les
noms Parents, adresse, classe de l'élève…) et, pour pouvoir les mettre à jour
facilement (par requête ajout et requête mise à jour) je ne l'ai pas scindée. Peut
être pourrais-je regagner sur les 55 secondes de la mort, par la scission ?
Mais zalors, pour rafraîchir les données, je devrais faire
multiplier les requêtes action : ajout de nouveaux parents, mise à jour des
adresses, ajout des nouveaux élèves…
Je m'aperçois que j'utilise très peu la clause Where dans
mes requêtes. Je sélectionne un max de champs. J'utilise peu de requêtes avec
trop de données ; et avec une requête "à usage multiple" je bâtis
plein d'objets.
Si je te suis, il faudrait que je fasse des requêtes, plus nombreuses
et "à usage unique" ? en utilisant plus la ligne "critère"
en mode création (ie where en SQL) ?
J'utilise peu les index. J'ai lu que mettre partout des
index a des effets pervers. Faut-il en mettre sur toutes les clés externes ?
Quelle raisonnement faut-il faire pour répondre à la question index/pas index ?
Bien à toi, et en te remerciant par avance de tes conseils précieux. |
|
|
|
Réponse n° 5
--------
le 31/05/2010 : 14:09
par 3Stone
Administrateur
|
Bonjour,
Citation :dans une base maison (Sconet, qui contient les noms Elèves, les noms Parents, adresse, classe de l'élève…)
Je ne connais pas... c'est une base Access ?
Citation :Je m'aperçois que j'utilise très peu la clause Where dans mes requêtes
Il faut absolument limiter aux données "utiles" et placer une clause Where sur un champ indexé.
Access fera transiter cet index et sélectionneras les enregistrements concerné. A défaut, tout prend le chemin de ta base frontale.
J'utilise peu de requêtes avec
trop de données ; et avec une requête "à usage multiple" je bâtis
plein d'objets.
Voilà le genre d'erreur "m o n u m e n t a l e" à ne pas commettre!
Encore une fois, en local, les données "sont là"... mais en réseau !?!
Au lieu de quelques données, tout ce qui est contenu dans ta première requête fait des aller/retour 
Il ne faut aussi sélectionner que les champs qui sont nécessaire à ce que tu souhaites faire, et non toute la table, voir deux ou trois tables... ce qui est très pénalisant!
Citation :J'ai lu que mettre partout des index a des effets pervers
Pas "partout"
La requête que exécutes une fois/jour n'est pas pénalisante. Mais les données qui transitent pendant les mises à jour et autres éditions doivent être limitées au minimum.
Cordialement,
Pierre(3stone) |
|
|
|
Réponse n° 6
--------
le 02/06/2010 : 19:54
par kolele
visiteur
|
Salut 3Stone,
Merci de tes conseils judicieux. J'ai entamé le grand ménage
sur les requêtes supports de mes Etats : suppression des champs inutiles, index
sur champs "critérisés" ("wherisés?!"). En test sur base
fractionnée, ça divise par 2 le temps d'exécution. Mais ça freine encore : 41
secondes !
Ça vient peut être de là : la requête utilise 5 DLookup. Contexte
: allouer des aides sociales selon une table Barème. Syntaxe :
DLookUp("[Montant annuel]","1 - ADDP : taux
et barêmes",[Quotient familial] & " between [Valeur plancher] AND
[Valeur plafond]") AS montant
DLookUp("[Lettre clé]","1 - ADDP : taux et
barêmes",[Quotient familial] & " between [Valeur plancher] AND
[Valeur plafond]") AS LettreClé
Question 1: Est-ce que je dois indexer aussi les champs
utilisés dans cette fonction ?
Question 2 : y aurait-il un moyen moins lourd que 5 dlookup
?
Je tire de tes remarques précédentes la maxime générale suivante
: on ouvre une requête spécifique pour chaque formulaire ou état, pour chaque
"besoin". Tu confirmes ?
Merci encore. Plus pour tes remarques de fond.
|
|
|
|
Réponse n° 8
--------
le 03/06/2010 : 18:06
par kolele
visiteur
|
Bonsoir 3Stone,
Je n'ai pas l'ouvre-boite du fichier que tu m'indiques de
télécharger sur le site Access web (mvps.org). Le fichier s'appelle
baslookup.bas : faut-il le renommer ? le placer quelque part dans windows ?
Commentaire plus général : sur les requêtes, et toutes les
betises "m o n u m e n t a l e s" commises par les bricoleuses, j'ai
trouvé assez peu de littérature. Le passage des bases en réseau est souvent
placé à la fin des manuels ; et sur les requêtes, on insiste que sur les
syntaxes. Donc, si tu avais une planche à l'usage des profanes sur ce thème, ça
rendrait un service signalé à l'humanité gestio-bricoleuse de données…
Bien à toi, |
|
|
|
 sujet actif
sujet clos
 Important!
 Nouveau message -
 Rectifier message
 Clôturer sujet
 Remonter
|
© 2004-2013 
