Discussion :

[Youpikai]

Bonjour,

Le problème doit être assez souvent récurrent mais j'ai besoin d'aide concernant la lenteur de ma base.

Celle-ci fait une soixantaine de Mo (ça ne cesse d'augmenter) car on ajoute des données tous les jours. C'est une grosse BDD qui génère beaucoup de choses dans l'optique de devenir une Big Data.

Elle dispose d'environ une centaine de tables (l'une d'entre elles contient plus de 100 000 lignes, 4 autres en contiennent environ 15 000, 5-6 ont environ un millier de lignes et les autres servent principalement de codification). J'ai aussi environ 200 requêtes, 250 formulaires (avec VBA sur une centaine d'entre eux), 6 Etats et 1 macro (Autoexec) ce qui donne évidemment une base assez lourde.

Lorsque je suis le seul a être sur la BDD, il n'y a pas vraiment de lenteur flagrante mais la base doit être utilisé en mode multi-utilisateur (environ 5 à 10 personnes doivent travailler dessus) et c'est là que le problème survient : il faut souvent attendre une quinzaine de secondes afin de passer d'un enregistrement à un autre et cela est très embêtant.

J'ai déjà essayé de fractionner la base mais c'était encore pire (bizarre car elle devrait être plus rapide grâce à ça), cependant, je n'avais pas mis les tables (base principale) au même endroit qu'à la base, je l'ai caché dans des sous-répertoires afin d'éviter d'y toucher, c'est peut être ça le problème de lenteur. Pensez-vous que je devrais la fractionner à nouveau mais la mettre au même endroit permettrait d'augmenter la vitesse ?

Auriez-vous une idée pour résoudre ce problème ou du moins réduire le temps ?

En espérant avoir de l'aide sur ce sujet, je vous souhaite une bonne journée.

PS : Est-ce normal que dès que j'ouvre ma base, même si je n'ajoute pas de données, sa taille augmente ? Aussi, je la compacte assez régulièrement pour permettre de résoudre certains problèmes.

[Jean-Philippe André]

Salut,

si tu veux faire du big data, ce ne sera pas stocke dans Access.

Sur le fond : avoir plus de 100 tables c'est un probleme de conception, avant de parler des aspects performances.

60Mo c'est loin de la taille maximum de 2Go d'une base.

Ne peux-tu donc pas envisager de faire un stockage sur un support adequat ?

[ylemasson]

Bonjour

Votre message est intéressant, car il évoque plusieurs choses très importantes lorsqu'on travaille de façon professionnelle sous Access :

Primo : Access n'est pas doué pour fonctionner en réseau. Vos problèmes de lenteurs sont normaux, car audela de 2 ou 3 utilisateurs, avec une qualité de réseau standard, vous allez commencer à le sentir passer. En tant que professionnel, j'utilise maintenant le MySQL pour le stockage des données, et là on y gagne vraiment tout : rapidité, sécurité, etc... fini les fichiers qu'il faut cacher pour le protéger des "suppressions accidentelles!" !

Deuxio : votre base grossit toute seule : c'est normal !... toute base Access possède la caractéristique de conserver en "interne" un "cash" de données issues des précédentes versions. Pour résoudre ce problème c'est très simple : vous devez la compacter (fichier / compacter et réparer le fichier). Votre fichier va maigrir d'un coup ! Faites le sur votre base de données, et votre IHM.

Tertio : Access n'est pas fait pour fonctionner avec trop de données. Ce n'est pas un SGBD performant pour le stockage. Gardez le uniquement pour l'interfaçage, et la grande souplesse du VBA.

Cdlt

[marot_r]

Oui Access fait parfois cela ceci dit le fractionnement est plus que recommandé pour une utilisation à plusieurs.

Personnellement j'ai expérimenté avec une dizaine d'utilisateurs sans problème particulier et avec un seul et de GROS problèmes de lenteur.
Access semble très sensible au réseau sans que j'ai pu comprendre pourquoi.
J'ai des fois des temps très rapides et des fois des temps très lent pour la même application.

Il y a quelques astuces pour améliorer les performances mais elles sont ponctuelles (un formulaire, une requête, un bout de code). Rien qui ait un impact global sur l'application.

Une possibilité car je pense que tu fais essentiellement de la lecture et que passer les phases de chargement ta BD est "Morte", serait de copier ta base en local avant chaque utilisation ce qui améliore sérieusement les performances.
Et tu peux aussi envisager l'utilisation d'un disque SSD qui est significativement plus rapide (et plus chère) que les disque traditionnels.

Et comme l'as dit Jean-Philippe André, Access n'est pas vraiment l'outil pour du Big Data.
Je te recommande une GROSSE BD genre Oracle, MS-SQL Server, DB2 ou MySQL avec un serveur dédié.
Pour MySQL je ne m'en suis jamais servi mais Oracle, MS-SQL Server et DB2 sont des bases conçues pour des gros volumes.
J'ai fait sourire un de mes administrateur MS-SQL quand je lui ai dit qu'au maximum j'aurai besoin de 2 Go de données pour un transfert des données d'une de mes BD Access vers un autre système.

ET attention quand on approche des 2 Go ou quand on sature Access n'envoie pas de message clair. Tu as des erreurs abracadabrantes qui ne correspondent pas du tout au problème.

A+

[patator_]

Celle-ci fait une soixantaine de Mo (ça ne cesse d'augmenter) car on ajoute des données tous les jours. C'est une grosse BDD qui génère beaucoup de choses dans l'optique de devenir une Big Data.

Je te recommande une GROSSE BD genre Oracle, MS-SQL Server, DB2 ou MySQL avec un serveur dédié.
Pour MySQL je ne m'en suis jamais servi mais Oracle, MS-SQL Server et DB2 sont des bases conçues pour des gros volumes.

J'ai l'impression qu'il y a une confusion à propos du big data. La conception d'une base de type Big Data est un véritable changement de paradigme. Il s'agit de traiter des volumes de données se comptant généralement au minimum en centaines de Go. C'est pour cette raison que les BDD relationnelles telles que MySQL, MS-SQL Server et DB2 peuvent devenir insuffisantes. Lorsqu'on parle de Big Data, les outils auxquels on pense sont souvent Hadoop ou Cassandra par exemple.
En fait, tu n'as peut être pas besoin d'un SGBD fait pour du Big Data, mais simplement de qqch avec de plus grandes capacités, auquel cas les BDD relationnelles mentionnées sont de très bonnes alternatives à Access. On peut d'ailleurs rajouter à la liste PostgreSQL ^^

[Youpikai]

Bonjour à vous 3 et merci pour vos réponses. Je vais vous répondre 1 par 1 pour éviter les confusions.

Salut,

si tu veux faire du big data, ce ne sera pas stocke dans Access.

Sur le fond : avoir plus de 100 tables c'est un probleme de conception, avant de parler des aspects performances.

60Mo c'est loin de la taille maximum de 2Go d'une base.

Ne peux-tu donc pas envisager de faire un stockage sur un support adequat ?

Concernant le nombre de tables, la base possède un tronc commun d'environ 30 tables (dont une bonne quinzaine servent uniquement à de la codification), mais j'ai besoin de sous-bases individualisées (2 tables par client), ce qui provoque donc une augmentation du nombre de tables. Concernant le stockage, j'étais dans l'obligation de travailler sur Access, donc pour l'instant, je ne peux pas faire autrement. A voir avec le temps si il est possible de changer de support.

Bonjour

Votre message est intéressant, car il évoque plusieurs choses très importantes lorsqu'on travaille de façon professionnelle sous Access :

Primo : Access n'est pas doué pour fonctionner en réseau. Vos problèmes de lenteurs sont normaux, car audela de 2 ou 3 utilisateurs, avec une qualité de réseau standard, vous allez commencer à le sentir passer. En tant que professionnel, j'utilise maintenant le MySQL pour le stockage des données, et là on y gagne vraiment tout : rapidité, sécurité, etc... fini les fichiers qu'il faut cacher pour le protéger des "suppressions accidentelles!" !

Deuxio : votre base grossit toute seule : c'est normal !... toute base Access possède la caractéristique de conserver en "interne" un "cash" de données issues des précédentes versions. Pour résoudre ce problème c'est très simple : vous devez la compacter (fichier / compacter et réparer le fichier). Votre fichier va maigrir d'un coup ! Faites le sur votre base de données, et votre IHM.

Tertio : Access n'est pas fait pour fonctionner avec trop de données. Ce n'est pas un SGBD performant pour le stockage. Gardez le uniquement pour l'interfaçage, et la grande souplesse du VBA.

Cdlt

1: La base a été créé en SQL pour être utilisé sur notre site internet et a été exporté sur Access afin de pouvoir travailler dessus en locale (quand je dit locale, c'est que la base n'est plus connecté à la plateforme mais se situe tout de même sur un disque réseau). Cependant, notre réseau internet est vraiment pourrie pour le moment, et c'est peut être cela qui cause des lenteurs.

2: Merci pour l'information, je m'en doutais un peu qu'Access augmentait la taille sans même rajouter d'informations mais je voulais avoir confirmation. Pour ce qui est de la compacter, je la fais assez régulièrement et en effet, elle gagne en mémoire chaque fois.

3: Comme dit plus haut, je n'ai pas le choix pour l'instant, je dois travailler sur Access.

Oui Access fait parfois cela ceci dit le fractionnement est plus que recommandé pour une utilisation à plusieurs.

Personnellement j'ai expérimenté avec une dizaine d'utilisateurs sans problème particulier et avec un seul et de GROS problèmes de lenteur.
Access semble très sensible au réseau sans que j'ai pu comprendre pourquoi.
J'ai des fois des temps très rapides et des fois des temps très lent pour la même application.

Il y a quelques astuces pour améliorer les performances mais elles sont ponctuelles (un formulaire, une requête, un bout de code). Rien qui ait un impact global sur l'application.

Une possibilité car je pense que tu fais essentiellement de la lecture et que passer les phases de chargement ta BD est "Morte", serait de copier ta base en local avant chaque utilisation ce qui améliore sérieusement les performances.
Et tu peux aussi envisager l'utilisation d'un disque SSD qui est significativement plus rapide (et plus chère) que les disque traditionnels.

Et comme l'as dit Jean-Philippe André, Access n'est pas vraiment l'outil pour du Big Data.
Je te recommande une GROSSE BD genre Oracle, MS-SQL Server, DB2 ou MySQL avec un serveur dédié.
Pour MySQL je ne m'en suis jamais servi mais Oracle, MS-SQL Server et DB2 sont des bases conçues pour des gros volumes.
J'ai fait sourire un de mes administrateur MS-SQL quand je lui ai dit qu'au maximum j'aurai besoin de 2 Go de données pour un transfert des données d'une de mes BD Access vers un autre système.

ET attention quand on approche des 2 Go ou quand on sature Access n'envoie pas de message clair. Tu as des erreurs abracadabrantes qui ne correspondent pas du tout au problème.

A+

Il faudrait que je réessaye le fractionnement mais je mettrai les tables au même endroit. La base est déjà en locale, elle se situe uniquement sur un disque réseau. J'essayerai de voir pour changer de plateforme mais je ne suis pas sûr d'avoir gain de cause.

Bonne journée.

[Jean-Philippe André]

Salut,

en fait c'est tout est directement lie a ta definition de Big Data

J'ai eu un client qui m'avait vendu un besoin big data, alors que c'etait juste leurs statistiques sur toute la france dans un fichier Excel a mettre en forme