choix et optimisation bdd

[bad wolf]

 

actuellement, j'ai une grosse base de données gérées sous access (pas le choix, elle est créée automatiquement à partir d'une appli dédiée)

 

sous access, la bdd est structurée comme suit :

dossier "année" / sous dossier "mois" / fichiers *.mdb

 

y a beaucoup de fichiers mdb, et énormément de données dans chaque fichier,

ce sont des historiques, avec des valeurs enregistrés toutes les 15 min (voir toutes les minutes pour certaines données ... la base existe depuis 2006, je vous laisse imaginer la taille du bidule )

 

pour des raisons pratique, je souhaite passer à une bdd compatible php, genre mysql

 

par contre, avec le nombre de données au total, je sais pas si c'est une bonne idée :reflexiomo6:

 

donc voila, est-ce que mysql continue de bien se comporter si une table contient beaucoup de données ? et quand je dis beaucoup, c'est BEAUCOUP ???

(par exemple, pour un des fichiers, il y a plus de 30000 enregistrement pour un seul mois ....)

 

y a une limite d'entrée? de taille peut-être?

 

faut peut-être partir sur plusieurs table, un peu à l'image de la structure access : des tables pour les mois et années ???

 

ou alors, il existe des bases de données un peu plus "spécialisées" la dedans? si possible compatible linux ??

 

a++

[bad wolf]

bon, me suis renseigné et apparement la seul limite c'est la taille du disque dur du serveur (et de la limitation du système de fichier)

 

donc je pense que ça va être bon !!

[FreeZou]

MySQL est pas mal pour des appli/sites web de taille petite à moyenne ( quoiqu'avec la version 5, il commence à se rapprocher d'un PostgreSQL ), le tout étant de savoir si ces données doivent juste être stockées ? ou stockées et utilisées de manières plus ou moins intensives ?

 

Si c'est juste une base de dépots, et un jour en 2042 on aura besoin du listing du 13 mars 2006 alors mySQL fera l'affaire, sinon peut-être faut il se tourner vers du plus "gros" Postgre, oracle ...

[bad wolf]

seule les dernières entrées seront intensément utilisées, (on va dire celles du dernier mois)

 

les autres seront consultées assez rarement, mais doivent être présentes quand même.

 

donc ça concorde avec ce que tu dis de MySQL

 

Me reste plus qu'à faire le transfert access --> mysql ^^

[bad wolf]

Bon voila,

j'ai fini de migrer la base vers MySQL

 

donc, celle-ci contient 152 tables pour un total de ... 330Mo environ

 

le problème c'est que l'affichage des entrées est longue, plus longue que lorsque j'attaquais directement la base Access ...

 

Y a-t-il une meilleure solution? autre que revenir sur Access ... ???

[FreeZou]

Tu veux dire depuis le script ?

[bad wolf]

je pense pas que ça change quelque chose avec le script

j'ai limité le nombre de requête, je peux difficilement faire mieux

 

Nan jpensais plutôt à un autre type d'organisation, peut-être une autre bdd que MySQL?

 

 

En fait l'appli doit afficher sur une page des états courants de plusieurs items,

et quand on clic sur un item, afficher son historique sur une plage donnée

 

je pense que je vais créer des tables supplémentaires qui ne contiennent que les états courants et qui seront mises à jour à chaque nouvel état

 

déjà ça va alléger l'appel de la page principal ....

[FreeZou]

Je t'avoue que "comme ça" assez dur de voir où est le problème.

Est-ce que tu as bien optimisé ta base ? Clés primaires, indexs, clés étrangères.

Je connais pas trop access, donc peut-être qu'il faut revoir un peu le schema de la table.

 

Après peut-être que tes appels à la base ne sont pas super optimisé, vérifie tes jointures, il faut que ca parcourt le moins de champs possibles.