Aller au contenu

choix et optimisation bdd


bad wolf

Messages recommandés

:hello:

 

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 :D )

 

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++

Lien vers le commentaire
Partager sur d’autres sites

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 ...

Lien vers le commentaire
Partager sur d’autres sites

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 ^^

Lien vers le commentaire
Partager sur d’autres sites

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 ... ???

Lien vers le commentaire
Partager sur d’autres sites

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 ....

Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
  • Statistiques des membres

    23 028
    Total des membres
    1 033
    Maximum en ligne
    Subaru
    Membre le plus récent
    Subaru
    Inscription
  • Statistiques des forums

    128,1 k
    Total des sujets
    1,7 M
    Total des messages
×
×
  • Créer...