Discussion :

[alexandre.beaujault]

Bonjour à tous,

Je tiens tout d'abord à remercier l'ensemble de la communauté qui m'a permit de faire de gros progrès sur access et le dev en général.

Je ne suis pas sur d'être au bonne endroit sur le forum mais je ne savais pas où poser ma question.

Si je vous écris c'est que je suis face à un problème très peut documenté au vu de mes recherches.

Voici le postulat
J'ai développée une application partager par un grand nombre de personne et traitant un "grand volume de données".
En gros, j'importe dans des tables de très grand volume de données issues de différente sources. Une fois les données injectées les utilisateurs peuvent travailler dessus.

Pour faire ceci, j'ai un conteneur pour les données sur le réseau et un pour l'interface qui est déployé chez les utilisateurs.

Avec le temps, la base data à grossit et atteint le Go. Étant en cours de monté de version, j'ai découpé cette base de données en répartissant les tables dans plusieurs conteneurs.

Mon soucis est que sur la version multi-conteneur le traitement d'un import de 55000 ligne mais pas loin d'une heure (j'ai abandonné avant la fin) alors qu'actuellement le même volume sur la prod (avec un seul conteneur) met moins de 10s.

Ma question est la suivante, qu'elles sont les règles de bonnes pratiques pour la découpe de ces conteneurs? je n'ai pas trouvé grand chose sur ce sujet et microsoft ne semble pas très bavard.

Je vous remercie par avance pour vos retours d'expérience qui me seront très utile.

Cordialement

[nico84]

Bonjour,

C'est quoi un conteneur ? un fichier access ?

Avec le temps, la base data à grossit et atteint le Go

Avec compactage quotidien ? Si oui il est temps de migrer les données sur un autre type de base - MSQL ou autre - ce qui n'interdit pas de conserver access en frontal. S'il y a des relations entre les tables elles doivent être dans la même base...

sur la version multi-conteneur le traitement d'un import de 55000 ligne mais pas loin d'une heure

C'est peut-être à cause d'un découpage malheureux ou d'un code non optimisé

[alexandre.beaujault]

Bonsoir,

Merci pour ton retour.
Je suis tout à fait d'accord pour dire qu'un autre moteur serai plus approprié. Malheureusement, je ne pourrais pas obtenir un tel moteur dans mon environnement.
Cette base a été construite au black afin de palier un manque des services techniques.

C'est pourquoi je cherche à augmenter le stockage en augmentant le nombre de fichiers du back-end.

L'ensemble des fonctionnalités semble répondre convenablement. Ce n'est que la partie import qui semble poser problème.

Voici comment on s'y prend:
Import des données brut dans une table en locale.
Création d'une table temporaire contenant les FK correspondants toujours en locale.
Injection des données dans la table de destination.

Afin d'être plus rapide, je pensais supprimer la génération de la table intermédiaire pour enchaîner une suite d'update champ par champ. Cela te semble-t-il opportun?

Aurais tu des pistes à me proposer pour optimiser ces importations.

Merci beaucoup pour ton aide

[nico84]

Aurais tu des pistes à me proposer pour optimiser ces importations.

J'ai pas tout compris mais il y a toujours plein de solutions au même problème.

- SQL server express, ou postgres sont de vraies bases de données gratuites qui marchent très bien, y compris en étant interrogées par access
- moins il y a de tables intermédiaires mieux c'est
- si je peux lire dans la base d'origine j'évite systématiquement de recopier les données dans une base intermédiaire

Par contre les bases access ont de sérieuses limitations et c'est incontournable

[marot_r]

Bonjour.

Est-ce que si tu mets ta BD backEnd en local tu as le même problème ?

Personnellement j'ai une BD qui est allergique au réseau, en local tout est beau en réseau c'est souvent à peine utilisable.
Des investigations faites lors d'un cas précédent de ralentissement avait identifié la présence d'un vieux protocole destiné à protéger les réseaux lent contre les demandes excessives.
Dans mon cas actuel, la cause reste inconnue car on a des variations significatives de performance, de quelques minutes à quelques heures pour exactement le même traitement.

A+

[alexandre.beaujault]

Bonjour,

Désolé je viens de voir ton retour. La notification n'a pas marché semble-t-il!!
Pour répondre à ta question, oui le problème se répercute en locale aussi.

J'ai réussi à obtenir en début de semaine l'installation de MSDE 2012 sur mon poste et sur le poste centrale.
Donc si tout ce passe bien je vais tenté de réécrire l'application pour ce nouveau moteur.
Une grande première pour moi qui n'ai jamais programmé sur SQL Server

Je risque donc de solliciter la communauté régulièrement quand je tomberai sur un os.

Merci encore à tous