Discussion :

[waspy59]

Bonjour,

j'ai développé une appli qui utilise une base de donnée access pour l'archivage des données (il sagit en fait une gestion de stock pour des laboratoire).

Cela fonctionne bien mis a par que l'acces à la BD est assez longue des qu'on atteind un certains nombre d'enregistrements :-(

Je souhaite donc passer par un autre systeme de BD mais je ne sais lequel choisir...

Pour info mon appli est monoposte, il sagit juste d'un systeme d'archivage en interne.

Que prendre comme systeme sachant qu'il doit etre gratuit, leger et facile d'utilisation et déploiement

merci pour votre aide

[TryExceptEnd]

Comparatif SGDB

[waspy59]

re,

j'ai deja lu ce comparatif mais comme je ne suis pas expert en BD (loin de là) le choix pour mon cas est loin d'être évident... d'ou ma question sur le forum

[Marc Lussac]

Tous le problème est la, par exemple tout en restant dans le monde Microsoft, si tu passe à Microsoft SQL -Server express (gratuit) , il va falloir tu tu devienne un ingénieur base de données SQL-Server, soit grâce à l'auto formation, soit grâce à une vrai formation, mais ca ne se fait pas en 5 minutes en théorie 1 an d'études, dans la pratiques au moins quelque semaines de formations ou d'auto formation.

[kedare]

pour ca , je te conseille firebird , c'est tres legé (quelques mo), auto-administé , et auto-optimisé

apres il faut programmer les formulaires qui vont avec par contre (le mieu pour ca serais carrement une application web)

[Spoutnik]

sqllite ?

facile à utiliser, de nombreuses langage permettent de l'attaquer, à priori performant en monoposte, pas besoin de serveur.
Par contre, je ne sais pas ce qu'il donne avec des volumes imortants.

[vmolines]

Avant de proposer x SGBD tous plus performants les uns que les autres, il faudrait peut être évaluer si oui ou non il est nécessaire de changer de base.

Je ne sais pas ce que stocke l'application et quels traitements elle effectue mais je pressens qu'une bonne remodélisation et une bonne utilisation de sa structure de données couvrirait amplement ses besoins.

Je peux me tromper mais pour "une application d'archivage monoposte", mon instinct me dit qu'access, bien utilisé, conviendrait tout à fait.

Si tu fournis une petite explication de ce que tu dois gérer comme données et que tu indiques comment tu as fait ta base, on pourra t'aiguiller. Là c'est impossible.

[Invité]

Un élément à mesurer est la volumétrie : quelle taille fait la base Access aujourd'hui, et quel est le taux de croissance annuel. Si ces mesures restent dans les cordes d'Access, alors il faut le conserver et l'optimiser, comme le dit vmolines

[waspy59]

re,

merci pour toutes ces précisions... après avoir bien réfléchi je pense en effet que access doit être suffisant et ceux pour plusieurs raisons:
- besoin d'un simple archivage monoposte
- structure des tables relativement simple (peux de connections inter tables)
- je connais déjà access ;-)

Mon seul point négatif et que je trouve que l'affichage des requetes est relativement long (2 a 5 secondes) dès qu'il y a plus de vingt lignes (5 à 8 colonnes par ligne) par tables... mais cela vient surement d'une mauvaise optimisation de mon code et de mes tables...

encore merci pour votre aide

[Invité]

Mon seul point négatif et que je trouve que l'affichage des requetes est relativement long (2 a 5 secondes) dès qu'il y a plus de vingt lignes (5 à 8 colonnes par ligne) par tables... mais cela vient surement d'une mauvaise optimisation de mon code et de mes tables...

Ou de l'absence d'index pertinent...

[vmolines]

Si tes données ne sont pas d'une grande confidentialité, tu peux peut être nous soumettre ton mdb. Où me la soumettre en message privé si tu ne veux pas que ça apparaisse en public sur le forum.

Je pourrai te donner mon avis en faisant un petit tour d'horizon de ton appli.

[DEV-10]

Avant de proposer x SGBD tous plus performants les uns que les autres, il faudrait peut être évaluer si oui ou non il est nécessaire de changer de base.

Je ne sais pas ce que stocke l'application et quels traitements elle effectue mais je pressens qu'une bonne remodélisation et une bonne utilisation de sa structure de données couvrirait amplement ses besoins.

Je peux me tromper mais pour "une application d'archivage monoposte", mon instinct me dit qu'access, bien utilisé, conviendrait tout à fait.

Si tu fournis une petite explication de ce que tu dois gérer comme données et que tu indiques comment tu as fait ta base, on pourra t'aiguiller. Là c'est impossible.

Vmolines
Quels sont les éléments à considérer pour voir si on doit abondonner acces pour autre choses ? sql server par exemple.

Merci

[vmolines]

Si vos données nécessitent un accès multi utilisateurs, il faut commencer à remettre en cause Access pour un SGBD client/serveur. C'est un SGBD fichier qui a des limites inhérentes à son format en termes d'accès concurrentiels.

Pour des applications monoposte ou faiblement multi utilisateurs (exemple : 1 utilisateur en modification et plusieurs en lecture), Access peut très bien faire l'affaire même pour des volumes de données assez importants.

[vdumont]

Une 20aine d'enregistrements avec quelques colonnes seulement et ca prend du temps ? Alors le problème n'est surement pas Microsoft Access (bien que je le déteste) mais fort probablement la façon dont tu inter-agis avec.

Revois ton adapteur de base de données et révise tes requêtes SQL.