Discussion :

[thomas.m]

Bonjour,

Je travaille actuellement sur une grosse base de données (une quarantaine de tables, environ 250 Mo compressée)

Il s'agit de données historiques et prévisionnelles de production en provenance d'usines à destination de nombreux pays.
Les données proviennent de nombreux systèmes d'information différents, j'ai donc beaucoup de tables de raccordement permettant de regrouper tout ça.
Le schéma ci dessous résumé grossièrement son fonctionnement:



Tous les jours, une dizaine de fichiers textes sont importés via un formulaires dans mes tables. Pour améliorer la performance, j'ai décidé de stocker le résultat de ma requête regroupant toutes les données dans la "table 1" : 425 000 lignes, 20 champs.
J'ai aussi besoin d'afficher des regroupements sur ces informations, à une "maille" ou "échelle" moins fine, pour optimiser encore, je stocke les résultats de ces requêtes dans les tables 2, 3, 3bis et 4.

Toutes les informations dont j'ai besoin sont contenues dans ces tables que je dois afficher dans des formulaires.
L'utilisateur doit pouvoir naviguer facilement d'une "maille" à une autre, j'ai donc opté pour des onglets, avec une application des filtres appropriés lors du basculement d'un onglet à un autre.
(Le sous formulaire contenant la table 3 a un sous formulaire 3bis)

En local tout va plutôt bien. Ma requête "Mise à jour" que j'effectue une fois par jour tourne en 3 à 4 minutes, puis ensuite j'accède à toutes les données très rapidement dans les formulaires (2 secondes pour l'ouverture, ensuite c'est fluide et agréable à manipuler).

Le problème est que je dois distribuer ce formulaire en lecture à d'autres utilisateurs.
J'ai donc suivi les tutoriaux rencontrés sur developpez.net, à savoir couper ma base en deux avec d'un côté, les tables sur le réseaux avec les requêtes et formulaire nécessaires à la "mise à jour"
sur le bureau : une base avec les formulaires de consultation, et les tables 1, 2, 3, 3bis, 4 liées.
Or à chaque ouverture du formulaire consultation .... ça rammme. Beaucoup. J'aimerais bien faire en sorte que la base de données charge ces tables une bonne fois pour toute en locale, et qu'elle arrête de rafraichir les données en permanences car celles ci ne changent qu'une fois par jour. Existe t il des paramètres permettant cela ? (qu'est ce que la temporisation OLE/DDE, intervale d'actualisation etc?)

Cet découpage me pose un autre problème : La macro de mise à jour (permettant de regrouper les données brutes et d'alimenter les tables 1, 2, 3, 3bis, 4 ... Elle tournait en 3 minutes en loca. Sur le réseau de l'entreprise ... aïe .. je n'ai jamais eu le courage d'aller jusqu'au bout de son exécution.
N'est il pas possible d'exécuter celle ci sur le serveur ?

Je pense que je vais devoir opter pour une base de données découpée en 3. Une "Mise a Jour" en locale alimentant la base "Données" sur le réseau, et les bases "Consultation" en local.

Qu'en pensez vous ?
Merci d'avance pour votre aide,

Thomas

[marot_r]

Compte tenu de tes contraintes j'approuve ta dernière suggestion qui va te donner le moins de travail.

Pour exécuter sur le serveur, as-tu un Access sur ton serveur et un accès au serveur ?

Sinon, il n'y a pas de miracle. Il faut que tu réduise les volumes de données qui transit en étant plus sélectif (ex : éviter les select *) ou que tu ne transfert tes données qu'au moment où tu en a vraiment besoin (par exemple en n'associant des données à un onglet qu'au moment où l'utilisateur demande à voir ces données).

Enfin vérifie tes listes déroulantes, elles peuvent consommer beaucooup de temps, là aussi une solution consiste à n'associer les données à la liste que quand l'utilisateur demande à la voir mais cela peut ammener à repenser ton interface.

Dernier point pour tes MAJ, regarde si tu peux utiliser des requêtes Pass-Thru (ou SQL direct) qui permettent d'envoyer du SQL natif à la source de données et de faire travailler celle-ci au lieu de ton poste. J'ai eu un cas où je suis passé de 1/2h de travail à 5 mn en utilisant cela sur une base Oracle.

A+

[thomas.m]

Merci Marot pour ta réponse.

J'ai réussi à améliorer énormément la rapidité de l'accès aux données en modifiant un peu ma base client comme ceci :
- j'ai lié normalement les tables "légères" contenant juste des noms de produits ou usines, pays etc. servant aux listes déroulantes.
en fait ma base de données permet aux utilisateurs de créer des alertes associées à chaque enregistrement dans les tables. Ces alertes sont stockées dans des tables liées, du coup il n'y a pas de problème au niveau de ces données: elles sont tout le temps à jour.
Ensuite j'ai créé une fonction "Synchronisation" pour les données regroupées qui fait en gros:
INSERT INTO Table1,2,3,4 IN myBaseClient SELECT * FROM Table 1,2,3,4 IN myBaseDonnées
j'ai rajouté deux paramètres sur chaque base : [dernière mise à jour] et du coup je recopie mes grosses tables que quand j'en ai besoin.
J'ai aussi trouvé une super fonction dans un tutoriel ici pour modifier en VBA la liaison des tables liées, ainsi je dispose d'un seul champ "Lien vers base Données :" et quand je pointe vers cette base, ma fonction synchro sait où aller faire le SELECT * IN et toutes mes petites tables liées sont aussi re-paramètrées d'un seul coup.

Maintenant que tu parles des listes déroulantes, c'est vrai que j'en ai sur 4 champs dans mes formulaires continus. Elles pointes vers des tables de 2 à 3 champs et de 50 à 200 enregistrements max. Je vais tester la différence avec et sans.

J'ai déjà divisé par deux les volumes car, mes données sont hebdomadaires sur deux ans : an un dans le passé pour l'historique, un dans le futur pour les prévisions. J'ai donc tous les formulaires pour l'historique, avec un SELECT * FROM Table1,2,3,4 WHERE Semaine<Now() sur mes 4 sous formulaires
et un formulaire pour les prévisions, avec un SELECT * FROM Table 1,2,3,4 WHERE Semaine>=Now()
Le fait d'effectuer un filtre sur les données de mes tables qui divise le nombre d'enregistrements par deux diviste t il bien le temps d'exécution ?

L'idée de ne charger les données que de l'onglet visible est une bonne idée, c'est vrai que l'utilisateur utilise rarement les 4 simultanément.
Il faudrait sur le OnLoad du formulaire principal désactiver les 4 sous-formulaires, et les activer uniquement si on bascule sur leur onglet.
Quelle propriété utiliser pour cela ? Quand je fais :
Me.[Sous-Formulaire].SourceObject = ""
les sous-formulaires n'apparaissent plus mais le formulaire est toujours aussi long à s'ouvrir.

J'ai aussi remarqué que mon problème de lenteur vient du deuxième onglet, qui est, je l'avoue, très particulier :



C'est un formulaire continue qui contient dans son pied de page deux formulaires en feuille de données.
En cliquant sur un enregistrement, grâce aux champs père fils, le formulaire de pied de page est filtré automatiquement, et je peux développer le détail grâce au petit "+". Très très pratique dans mon cas. C'est comme ça que j'ai pu détourner l'impossibilité d'avoir un sous formulaire dans un formulaire continu.

J'ai aussi beaucoup de mise en forme conditionnelles, de couleurs etc .. Je vais essayer d'épurer tout ça pour voir la différence.

Pour le SQL pass-thru je vois très bien ce que tu veux dire, cependant en réseau je suis pas au top. Je suis sur un réseau d'entreprise classique, Access n'est présent que sur les postes individuels, je suppose donc qu'il n'y a pas moyen de faire travailler le serveur à notre place du coup ?

[marot_r]

Quand je fais :
Me.[Sous-Formulaire].SourceObject = ""
les sous-formulaires n'apparaissent plus mais le formulaire est toujours aussi long à s'ouvrir.

C'est que le pb ne venait pas de là :-).

faire travailler le serveur

Désolé ambiguité de terminologie, je parlais du serveur de base de données : la machine sur laquelle est installé la base de données Oracle que j'utilise. Avec une requête pass-trhu c'est la base de données Orcale (donc son serveur) qui fait le travail au lieu que ce soit le poste du client.

Cette solution n'est peut-être pas applicable, certains DBA sont TRÈS réticents à l'autoriser car ils craignent que les requêtes ne preinnent trop de puissance au détriment des autres usagers. D'autres serveurs de BD n'autorisent simplement pas ce genre de requête.

A+

[thomas.m]

J'ai réglé le problème de la consultation des données sur ma base client.
Je vais finalement opter pour un modèle à deux bases : client et données.

la client : en local
la données : sur le serveur

Les mises à jour se feront en ouvrant directement la base de données située sur le serveur. J'essaye actuellement d'optimiser ma suite de requêtes de regroupements.
J'ai remarqué qu'en retirant les clés primaires de mes tables 1,2,3,4 les tables se remplissent deux à trois fois plus vite. La mise à jour descend donc à quelques minutes, ce qui est bien pratique.
Sur mes tables client les clés primaires sont toujours là, ainsi la consultation n'est pas ralentie.
Donc en gros pas de clés dans la base qui stock les données, et des clés sur la base de données client.

[marot_r]

Bonne idée, la suppression des clefs primaires, car si tes données sont en lectures seules cela ne pose pas de problème. Les données sont supposées 'propres' dans les systèmes d'origine donc les mesures de sécurités peuvent être plus légères dans ton application.

A+

[thomas.m]

Bonne idée, la suppression des clefs primaires, car si tes données sont en lectures seules cela ne pose pas de problème. Les données sont supposées 'propres' dans les systèmes d'origine donc les mesures de sécurités peuvent être plus légères dans ton application.

A+

Tout à fait oui.
Bon désormais mon gros gros formulaire s'ouvre en une poignées de secondes et son utilisation est désormais très fluide, c'est super.
La mise à jour quotidienne s'effectue que sur le serveur en 5 min, ce qui est largement acceptable.
Problème résolu.

Morale : ne pas chercher à mettre des tables liées de partout, des clés primaires, et des intégrités référentielles dans les TRES grosses tables

A+

[marot_r]

Morale : ne pas chercher à mettre des tables liées de partout, des clés primaires, et des intégrités référentielles dans les TRES grosses tables.

Oui mais je dirai plutôt "ne pas hésiter à supprimer tables liées de partout, des clés primaires, et des intégrités référentielles" si on a des problèmes de performance et que l'application se prête à la suppression de ces éléments de structuration et d'intégrité des données .

Ton appli est du genre entrepot de données pour statistique est se prête particulièrement bien à ce genre de simplification, ce n'est pas forcément le cas de toutes les applications.

A+