Discussion :

[Masamunai]

Bonjour,

Je développe actuellement une application sous VB2008 se servant intensivement de tables de données.
Afin qu'elles que les modifications sur ces tables restent sauvegardables après fermeture de l'appli, j'ai décidé de mettre ces tables dans un fichier externe au lieu de built-in. Access m'a paru tout indiqué pour ça.

Maintenant que j'ai mis toutes mes tables dans mon fichier Access, mon appli VB.Net les charge toutes en mémoire au démarrage, ca prends déjà quelque secondes alors que je ne fait que commencer...
Mais après le chargement initial, pas de problemes c'est "fluide".

Je me suis donc dit que si je cherchait à "optimiser" mes tables Access, le chargement serait peut être + rapide ? et en effet il y a un bouton "Analyse des performances" qui m'a permis de trouver où mettre des indexs, clés primaires et autre relations...

Je n'ai pas l'impression que cela ait changé un kopeck au chargement de mon appli...
Les relations et autres contraintes importées compliquent enormément mon implémentation de listes déroulantes sur certains champs par exemple...

Ma question est, d'un point vue conception, cela en vaut-il la peine que je passe un mois supplémentaire à apprendre access afin de maitriser un minimum les relations et autres contraintes ?
Ou le + simple reste de laisser mes tables telles quelles, sans relations ni quoi que ce soit, et me contenter d'un chargement de mon appli de 30secs ?

[Invité]

Bonjour

Une conception solide est un gage à long terme d'une bonne stabilité et d'une amélioration plus facile.

Si tu nous expliquais ton schéma, cela permettrait aux membres du forum de te donner un coup de main.

Philippe

[f-leb]

bonjour Masamunai, Philippe,

je connais à peine VB.Net mais ...

Maintenant que j'ai mis toutes mes tables dans mon fichier Access, mon appli VB.Net les charge toutes en mémoire au démarrage

Je sais qu'on peut "se connecter" à une base de données mais par contre qu'entends-tu par "charger en mémoire" ?

[Masamunai]

Pour f-leb:

Mon appli vb.net "charge" les données de ces tables dans des objets VB.NET appelés DataTables, lesquelles peuvent etre utilisées par l'appli quand j'y fait appel via des instructions. Cela signifie que mon appli travaille en mode "déconnecté" après le chargement de toutes les tables de mon fichier Access, puis se reconnecte à la fermeture de l'appli si et seulement si une ou des datatables ont subi des modifications, pour finalement se déconnecter de nouveau.

Pour Philippe :

Qu'est ce que tu entends par "schéma" concretement ? une capture d'ecran de la page des Relations ? ou autre chose ? (je demande pour pouvoir repondre precisement a ta question)

EDIT: je vais toujours donner quelques éléments de réponse :
Mon Appli est en fait une sorte de formulaire à 3 "volets":
- le 1er est l'interface principale (cf. piece jointe) qui permet à l'utilisateur de comparer 2 "sets", chacun construit à partir de comboboxs dont les listes déroulantes se basent sur les données des tables Access (+ filtres built-in si besoin est)
- le 2e est un conteneur a onglets, chaque onglet contenant affichant une des tables Access. Chaque table affichée est modifiable. Il y en 18 avec 35-40 champs. 3 ont + de 500 enregistrements.
- le 3e suit le même principe que le 2e, sauf que les tables affichées sont + "techniques" (pour connaisseurs only). Ces tables proviennent également de la base Access. Toutes sont de petite taille.
Lorsque je dis que les Tables sont "modifiables", c'est par l'intermediaire de mon interface .net, car l'utilisateur n'aura pas forcement le logiciel Access installé, alors qu'un executable fonctionnera partout.
Concretement cela signifie, entre autres, qu'il faut que je convertisse certains de mes champs sous forme de listes déroulantes, lesquelles prennent leurs valeurs sur une des tables dites "techniques". La question que je me pose alors pour ce probleme precis: je fait mes listes déroulantes sous Access, puis je croise les doigts que mon appli VB.NET me les importera niquel telles quelles, avec toutes les contraintes/requetes/relations qui vont avec ? ou alors ca foutrait trop le schmilblick et vaudrait mieux que j'importe mes tables "nues" puis convertir mes champs en listes déroulantes sur VB2008 ?
Il y a surment d'autres problemes inhérents à la conception, telles que les champs à NULL interdit ou autres dont je n'ai pas encore idée...

En bref, je pense (mais je peux me tromper) que si j'evite à mon appli des instructions de SGBD, il s'en retrouvera + "léger" à l'utilisation ? (en gardant a l'esprit que l'utilisateur n'aura que le .exe + le .accdb, rien d'autre)

[Invité]

Re

Oui je voulais parler de la fenêtre relation.

Le fait que tu charges les tables dans ton application me fait penser que ce n'est plus un problème Access, mais VB.net (dans ce cas ce n'est pas le bon forum).

Cependant ce forum peut t'aider pour les tables.

Philippe

[Masamunai]

Bonjour Philippe

Oui en effet c'est toute la question justement entre Access ou VB.NET.

Pour resumer j'ai 2 possibilités :

A. Soit je considere mon fichier Access comme un simple fichier de stockage. Dans ce cas, je vais rendre ses tables non-modifiables autrement que par l'appli vb.net, et les tables n'auront aucune relation entre elles, juste stockées telles quelles. Mes colonnes calculées ou autres champs à combobox devront etre tous implémentés dans mon appli. Idem pour les contraintes de champs et relations.

B. Soit je build un super fichier Access blindé avec toutes les relations/contraintes, tous les champs de mes tables vérifiés s'il faut une combobox, une valeur numeric ou texte, etc... et champs calculés tous prêts.
Là normalement quand mon appli chargera les tables, il chargera aussi les relations/contraintes et le reste (mais je n'en suis pas sûr).

Entre les 2 options, on voit que l'option A aura pas mal d'instructions à faire dans l'appli (et sera aussi plus "lourd" à l'utilisation) mais le chargement devrait être assez rapide (?).
En revanche, l'option B "laisse la main" au designer de VB2010 qui devrait mettre chaque chose à sa place automatiquement lors de l'importation au chargement de l'appli. Du coup, j'aurai presque pas grand chose a coder et l'appli a priori devrait fonctionner de façon + "fluide" (?).

Si vous me conseillez l'option B, je serai dans le bon forum, sinon je retourne au forum VB.NET lol.

EDIT: ci-joint les relations, je précise que je suis débutant est que ces relations paraitront surement du grand "n'importe quoi" mais au moins elles montrent quels champs sont liés. Je précise aussi que l'optimiseur automatique de relations m'a mis des indexs je ne sait où partout...

EDIT2: je viens de tester, VB2010 importe effectivement les relations, les indexs et clés primaires, les types de données de chaque champ, et je peux aussi lui demander les "vues" mais là je ne vois pas trop à quoi elles pourraient me servir et je n'en ai pas fait sous access de toutes façons :s
Pour vous donner une idée du temps de chargement de toutes ces tables au démarrage de mon appli (+ le code gérant l'interface screenshotée post précédent), ca prends 15 bonnes secondes. Imaginez quand je vais commencer a coder le "core" de l'appli...

[ilank]

Bonjour,
.Net comme Java sont des environnements autorisant le multithreading.
Ici, utiliser un backgroundworker pour charger les données est envisageable.
Peut-être aussi, serait-il mieux de ne charger en mémoire que ce qui est utile à un instant t.