Conseils concernant la nécessité ou pas de migration

Bonsoir à tous,

En tant que parfait novice en programmation (je n'ai réellement appris que l'assembleur, et ce n'était pas hier!, depuis j'ai bricolé un peu avec VB,net) je viens solliciter de votre part quelques conseils*!
Grâce à différents tutoriaux glanés ça et là sur le net (et surtout sur ce site), j'ai développé mon application sous Access
Au fil du temps j'ai peaufiné cette application selon mes besoins et je l'ai remplie..remplie..et maintenant certaines tables dépassent les 100 000 enregistrements et cela commence à ramer sérieusement*!
A noter que j'ai essayé de maximaliser la notion de base relationnelle*: malgré le nombre de tables et d'enregistrements le fichier ne fait que 90Mo

Ces ralentissements ne feront logiquement que s'amplifier, et je dois maintenant envisager une optimisation de l'application ou sa migration vers une autre structure ( client/serveur?) que j'aimerais basée sur des programmes si possibles gratuits

J'ai pour cela regardé un peu partout sur le net, et j'avoue ne pas être arrivé à me faire une idée bien claire de la solution «*optimale*»

1) Est il normal qu'une application Access de plusieurs tables >100 000 enregistrements rame au niveau du chargement des formulaires, et surtout pour les formulaires de recherche (tel que décrit à http://cafeine.developpez.com/access...echerchemulti/)
J'ai essayé de limiter la requête à 100 lignes, mais cela n'accélère pas le chargement, c'est du si j'ai bien compris au fait qu'Access charge toutes les tables avant de les filtrer

2) J'ai essayé d'exporter certaines tables vers SQL Server Express, est ce que cette solution (SQL Server + Access en frontal) permettrait de rendre l'appli plus fluide*? A priori non, d'après ce que j'ai lu dans le forum, mais l'avantage serait de pouvoir encore me servir de ce que j'ai déjà fait sous Access pour développer en parallèle une nouvelle application

Je pense donc que la solution passe par une structure client /serveur* en utilisation locale, monoposte : mais obtient on les mêmes performances avec PHP+MySQL et VB+SQLServer*?

3) J'ai fait quelques essais de VB sur SQL Server Express , mais je n'ai pas été convaincu par la rapidité (mauvaise programmation*?)

4) Quand je vois la rapidité de certains site (tel que http://www.wikitimbres.fr/), je me dis qu'il vaudrait mieux PHP +MySQL (ou autre), mais MySQL permet il facilement de créer des liens entre tables et surtout je redoute (peut être à tort) la partie réalisation de l'interface graphique de la partie client (je suis sûrement trop formaté Windows )

J'ai bien conscience que certaines de mes questions sont sûrement confuses et mélangent un peu de tout, mais c'est bien pour cela que j'ai besoin de conseils

Par avance, merci et bonne soirée
Bertrand

Avec un SGBDR client/serveur il faut programmer en client serveur et non pas en base "fichier". Autrement dit reconcevoir toute votre application et ne plus jamais utiliser le concept de table côté client, mais celui de requête SQL.

A +

Bonsoir et merci pour votre réponse,
C'est bien ce que je craignais, il va y avoir du boulot !
L'avantage est que cette appli étant perso , je n'ai pas de contrainte de temps et que pour moi la programmation est un hobby !
J'aimerais cependant, pour ne pas me fourvoyer, avoir confirmation que :
- une BDD de la taille évoquée justifie un passage en client/serveur même en utilisation locale mono-utilisateur
- le couple VB.net + SQL Server permet des temps de réponse similaires à ceux des sites précédemment cités
L'idée étant de transférer les tables d'Access vers SQL Server, et de continuer dans un 1er temps (le temps d'apprendre l'autre approche) à l’utiliser comme cela.
Est ce selon vous une approche "raisonnable" ?
Bonne soirée
Bertrand

Citation:

---

Envoyé par 105rn2

Bonsoir et merci pour votre réponse,
C'est bien ce que je craignais, il va y avoir du boulot !
L'avantage est que cette appli étant perso , je n'ai pas de contrainte de temps et que pour moi la programmation est un hobby !
J'aimerais cependant, pour ne pas me fourvoyer, avoir confirmation que :
- une BDD de la taille évoquée justifie un passage en client/serveur même en utilisation locale mono-utilisateur

---

Comme vous l'avez justement noté, les SGBDR à base de fichier nécessite de manipuler l'intégralité du fichier, même si c'est pour lire une ligne. De plus c'est un processus de lecture physique (disque).
Dans les SGBDR C/S les données sont mise en mémoire et les lectures comme les écritures se font en RAM et jamais sur le disque. De plus l'unité de lecture est la page (8 ko env), c'est à dire bien moins qu'une table et beacoup moins encore qu'un fichier.
Le rapport de vitesse est donc supérieur à 10 000 fois.

Citation:

---

- le couple VB.net + SQL Server permet des temps de réponse similaires à ceux des sites précédemment cités

---

Je dirais même beaucoup plus, mais tout dépens de la volumétrie,des données manipulées. MySQL étant d'une rapidité correcte (et contrairement à une légende, rarement devant Oracle ou SQL Server) sur de très petite bases, mais dès que le volume augmente, Oracle ou SQL Server sont très loin devant...
Lisez le benchmark que j'ai effectué comparant MySSL, PG et SQL Server :
http://blog.developpez.com/sqlpro/p9...lles-en-sql-1/

Citation:

---

L'idée étant de transférer les tables d'Access vers SQL Server, et de continuer dans un 1er temps (le temps d'apprendre l'autre approche) à l’utiliser comme cela.
Est ce selon vous une approche "raisonnable" ?
Bonne soirée
Bertrand

---

Oui, l'approche est raisonnable. De plus l'effort n'est peut être pas à faire sur toutes les tables.

A +

Bonjour,

Pour répondre à vos questions concernant Access :

Citation:

---

[1) Est il normal qu'une application Access de plusieurs tables >100 000 enregistrements rame au niveau du chargement des formulaires, et surtout pour les formulaires de recherche (tel que décrit à http://cafeine.developpez.com/access...echerchemulti/)
J'ai essayé de limiter la requête à 100 lignes, mais cela n'accélère pas le chargement, c'est du si j'ai bien compris au fait qu'Access charge toutes les tables avant de les filtrer

---

Tout dépend de votre application.
J'ai une appli Access avec près de 300000 lignes dans une table, 2 autres tables avec près de 100000 lignes et ça ne rame pas du tout, la base fait à peine 40Mo.
Avez-vous placé des index appropriés, choisi les bons types de données pour vos colonnes ?

Citation:

---

2) J'ai essayé d'exporter certaines tables vers SQL Server Express, est ce que cette solution (SQL Server + Access en frontal) permettrait de rendre l'appli plus fluide*? A priori non, d'après ce que j'ai lu dans le forum, mais l'avantage serait de pouvoir encore me servir de ce que j'ai déjà fait sous Access pour développer en parallèle une nouvelle application

---

Il faut différencier le fait de lier une table présente dans SQL Server dans votre base Access (pas performant) et le fait de créer un fichier adp avec Access (fonctionnement client/serveur, performant).

Comme le dit SQLpro, il y a de toutes façons un gros taf de reconception pour passer sur un fonctionnement client/serveur. Par contre, il y a peut-être moyen d'optimiser encore votre appli Access existante...

@+

Bonjour et merci à tous 2 de vos réponses,
C'est vraiment sympathique de votre part, de prendre le temps de répondre à un béotien comme moi, qui pose des questions " de base" (pour rester poli) et qui ont surement déjà leur réponse par ailleurs dans ce forum.
Mais encore une fois merci, car j'étais complétement perdu !
Voila ce que j'en conclue :
- mon appli Access va encore me servir un moment, quitte à l'optimiser un peu si c'est possible (et en profiter pour la "nettoyer" en normalisant le noms,...)
- en parallèle, je vais étudier sa migration partielle ou totale vers une structure C/S, car les ralentissements ne feront qu'empirer. Pour cela, j'ai commencé à étudier les différents tutos de ce site, et j'essaierai à l'avenir de filtrer mes questions sur ce forum !

Au risque de me contredire, concernant l'optimisation d'Access, il y a une question que je me suis toujours posé (sans jamais osé...)
En terme de performances, ai je intérêt à baser un formulaire :
- directement sur les tables
- sur une requête minima (spécifique à ce formulaire)
- sur une requête bcp plus large, reprenant tous les champs possibles
La réponse dépend à priori du fonctionnement d'Access que je ne connais pas :
-soit il charge la requête à chaque fois : dans ce cas, le mieux serait la requête minima
- soit il la garde en mémoire : dans ce cas, la requête max évite de recharger les données
J'ai par exemple (dans un souci de simplification) basé mon formulaire de recherche mufti-criteres sur une requête max (excédant de bcp le nbre de champs nécessaires), ceci explique peut être le temps de chargement ?
Pour info, la requête s'ouvre en 2 ou 3s, le formulaire en + de 10s ce qui commence à être désagréable, sans être cependant rédhibitoire

Encore une fois, merci pour votre patience et vos conseils
Bon WE
Bertrand

Bonjour,

Citation:

---

Au risque de me contredire, concernant l'optimisation d'Access, il y a une question que je me suis toujours posé (sans jamais osé...)
En terme de performances, ai je intérêt à baser un formulaire :
- directement sur les tables
- sur une requête minima (spécifique à ce formulaire)
- sur une requête bcp plus large, reprenant tous les champs possibles

---

D'une manière générale, faites une clause SELECT comme source de votre formulaire avec le strict nécessaire. Vous pouvez la construire de manière dynamique à l'ouverture (pour filtrer par exemple).
Postez sur le forum Access si vous voulez plus de détail.

@+

Bonjour et encore Merci,
En fouinant sur le site, j'ai trouvé pleins de tutos intéressants, et j'ai commencé à reprendre mon appli en suivant la normalisation des noms (il y en a plusieurs centaines)
J'en ai donc pour un moment !

J'aurais ensuite à modifier la source de mes formulaires pour optimiser un peu !
Je regarderai ensuite sur le forum, pour voir s'il y a d'autres astuces et regarderai comment programmer en client/serveur

Encore une fois merci pour tout !!!
Bertrand