Optimisation de base

Version imprimable

17/07/2007, 21h19
lbrun79

Optimisation de base

Bonjour,

Je souhaite optimiser les temps de réponses de mes bases liées.

Je voudrais savoir si le nombre de colonnes d'une table influence les performances (j'ai une table qui contient 66 champs, 18000 enregistrements pour une taille d'environ 16 MO qui rame un peu .Est-ce trop ?)

Je voudrais savoir si des champs taillés trop larges sur une table peuvent poser des problèmes de performance. (si je somme les champs de type Texte de ma table précédente j'arrive à près de 2000 caractères..est-ce trop ?)

J'ai lu quelque part qu'il ne faut pas utiliser l'outil de gestion des relations entre tables dans Access .. est-ce vrai ? faut-il ne se limiter qu'aux tables auxquelles on applique des contraintes d'intégrité référentielle ?

J'utilise Acess 2002

Merci pour vos réponses.

Laurent
17/07/2007, 23h55
Maxence HUBICHE

Citation:

Envoyé par lbrun79

Je souhaite optimiser les temps de réponses de mes bases liées.

En voilà une chose qu'elle est bonne...

Citation:

Envoyé par lbrun79

Je voudrais savoir si le nombre de colonnes d'une table influence les performances (j'ai une table qui contient 66 champs, 18000 enregistrements pour une taille d'environ 16 MO qui rame un peu. Est-ce trop ?)

Au vu de ce que tu dis, tu as une toute petit base de données. Ri-Di-Cule. :lol: :lol:
Donc, en terme de performances, tu ne DEVRAIS pas avoir trop de problèmes.
Déjà, c'est une bonne chose !

A ce niveau là... juste une remarque : 66 Champs !!! C'est énorme !
Quand je dis, ENORME, c'est en rapport avec une base de données traditionnelle, pas de rapport avec les limites d'Access.
Ma question serait plutôt : tu es sûr que ta base de données est bien conceptualisée ?

Citation:

Envoyé par lbrun79

Je voudrais savoir si des champs taillés trop larges sur une table peuvent poser des problèmes de performance. (si je somme les champs de type Texte de ma table précédente j'arrive à près de 2000 caractères..est-ce trop ?)

Le type Texte d'Access, c'est l'équivalent du type VarChar dans d'autres systèmes (SQLServer par exemple). Seuls les caractères saisis sont stockés. Tu peux donc calculer la taille MAX d'un enregistrement. Pas sa taille exacte. 2000 caractères... tu es à peu près à 1/32ème des limites d'Access :lol:

Citation:

Envoyé par lbrun79

J'ai lu quelque part qu'il ne faut pas utiliser l'outil de gestion des relations entre tables dans Access .. est-ce vrai ? faut-il ne se limiter qu'aux tables auxquelles on applique des contraintes d'intégrité référentielle ?

Oula oula !

Bon alors, je ne sais pas qui a raconté qu'il ne fallait pas utiliser les relations, mais c'est un benet ! Tu oublies ça car c'est une aberration complète.

Normalement, tu devrais TOUJOURS avoir l'intérité référentielle d'activée dans ton modèle (sauf cas hyper spécialisés, mais j'ai pas trouvé. Je me réserve juste une porte de sortie :lol: )
Il existe des situations où l'application de l'intégrité référentielle est IMPOSSIBLE, c'est lorsque des tables sont liées (ce qui n'a pas l'air d'être ton cas)

Suite à cela, quelques conseils :
- Surveilles tes index. Assures-toi que tes champs sont correctement indexés. Fais attention à ne pas mettre trop d'index dans les tables sur lesquelles il y a souvent des opérations de mise à jour (Ajout, Mise à jour, Suppression)
- Compacte régulièrement ta base de données
- Assures-toi que le modèle conceptuel est bien conforme à ta base.
18/07/2007, 23h37
lbrun79

Optimisation de base .. suite

Bonsoir,

Merci pour la réponse.

En fait, ma base contient 70 tables pour un totalde 90 MO ..effectivement pas de quoi fouetter un chat, sauf que trois de ces tables ont plus de 60 champs et qu'elles contiennent plusieurs milliers d'enreg.

Sur ces tables, je note des temps de réponse assez moyens surtout lorsque, dans certaines situations, je dois les balayer entièrement à l'affichage d'un formulaire (pour déterminer toutes les factures non payées à la date d'aujourd'hui pour les relancer par. ex). Les accès aux autres tables sont par ailleurs satisfaisants.

Penses-tu qu'en éclatant ces trois tables, je noterais des améliorations au niveau temps de réponse ?

Une fois optimisé, quel est le ratio normal entre une éxecution en local et une exécution avec un serveur distant ?

Merci.

Laurent
18/07/2007, 23h49
jolemoine

optimisation, le sujet me concerne

Bonjour Maxence HUBICHE,

en ce moment je conçoit une base de données, pour le moment je ne possède que 70 enregistrements pour les essais, le but est de rassembler les incidents sur un système.

La table principale qui comporte tous les champs possèdent 94 champs issus d'un long formulaire unique.

il y a quelques tables annexes qui comportent les valeurs des listes déroulantes.

alors d'après ce que j'ai put lire ma table principale comporte trop de champs?

;)
19/07/2007, 14h10
Maxence HUBICHE

@lbrun79 :
70 tables, ca commence à faire un gros bébé.
Access est-il adapté pour ce genre de choses (:koi:) ?
Ne serait-il pas préférable de faire une migration de tes données sur une base SQLServer (msde) et de créer un adp dessus ?

Quant à ton parcours pour les factures impayées, je me demande si la mise en place d'index bien placés n'améliorerait pas le temps de traitement.

Quant à la différence réseau/local, c'est simple !
Tu dois faire transférer toutes les données que tu interroges sur le réseau.
Si tu as un réseau gigabit et que tu es tout seul dessus, 10Mo vont passer comme une lettre à la poste !
Si ton réseau est à 100Mb et que vous êtes 1000 à bosser dessus et qu'en plus il y en a deux dans le groupe qui ont installé kazaa ou eDonkey et téléchargent à mort, tu vas ramer bien comme il faut :lol:

D'où le retour à la solution SQLServer (MSDE) + Adp, qui ne feraient transiter sur le réseau que les données interrogées, et pas l'ensemble des données sources comme dans le cas d'une BDD Access.

@jolemoine
Je n'ai pas dit qu'il y avait trop de champs !
J'ai dit qu'il fallait regarder si c'était conforme à une analyse conceptuelle, parce que cela fait vraiment beaucoup de champs.
Mais, si c'est conforme au modèle conceptuel (bien formé) alors go !
20/07/2007, 00h14
lbrun79

Bonsoir,

Merci pour cette réponse.

Effectivment l'appli est conséquente aujourd"hui.. elle tourne depuis 4 ans sans trop de problème et le partie cliente fait environ 50 MO et les temps de réponse pour certaines requêtes commencent à devenir rédhibitoires..

Il m'est impossible de vendre à mon client une refonte complète du système. Si je passais simplement en SQLServer en conservant mon client actuel, aurais-je les mêmes problèmes de performance ou faut-il tout changer pour améliorer ces temps de traitements.

Je sais que ce n'est pas l'objet de ce forum, mais est-ce qu'au passage tu ne connaitrais une petite fonction Access qui me donnerait la taille exacte de mes tables sous Access. J'ai mis au point une petite fonction d'archivage et je voudrais povoir afficher la taille des mes tables avant et après.

D'avance merci.
20/07/2007, 04h36
Invité

Bonjour

Un petit lien vers cette contribution, cette outil te permettra de connaitre la taille des objets de ta base.

Starec
20/07/2007, 06h54
lbrun79

Bonjour,

Merci pour ce lien.

Je connaissais déjà cet utilitaire..

il ne travaille malheuresement pas avec les tables liées et c'est justement de cela dont j'ai besoin.

Je vais m'en inspirer pour essayer de touver la solution à mon problème.

Laurent
20/07/2007, 15h26
jolemoine

Bonjour Maxence HUBICHE,

au départ j'étais parti sur un formulaire avec des onglets (7), mais j'avais pas réussi à les lier et comme le temps préssait pour rendre mon "devoir" et comme je ne suis pas développeur de formation, simplement je titille un peu Acces et pour les patrons c'est moins cher qu'un vrai développement, bon bref j'ai repense mon formulaire pour en faire un seul bien long je trouve quand même.

cela marche et je vais suivre tes conseils pour voir si tout cela est conforme.

@Starec merci pour le lien, utilitaire intéressant.

;)