20-12-2008, 01:38 AM
Juste un petit lien
http://dev.mysql.com/doc/refman/5.0/fr/c...ables.html
Donc en gros MYSQL stockant ses tables dans des fichiers risque de prendre plus de temps à trouver la table en question dans le dossier avant de commencer à chercher.
Et il y a sans doutes des méthodes pour limiter le nombre de table, on peut faire du réalisme sans pour autant avoir énormément de table.
Pose toi aussi la question de ce qui est fixe et de qui ne l'est pas! Es tu sur que certaine donnée n'ont pas à être dans des fichiers de configuration?
Pour savoir si une donnée doit être dans un fichier plutôt qu'une bdd:
- on regarde le nombre de donnée si il y en a ou y aura peut être plus de 100 la réponse est: table
- on regarde si les modifications fréquentes sont nécessaire (modif par tous les users plusieurs fois par jour) si c'est ou sera peut être fréquent la réponse est: table
- on regarde si l'on va avoir besoin d'obtenir une donnée autrement que par la seul clef si c'est ou sera peut etre le cas la réponse est: table
Dans les autres cas il peut être envisager de passer en fichier et d'éviter la lourdeur de l'appel à Mysql. J'ai mis en gras pour bien faire comprendre qu'il faut avant penser à l'évolutivité du script...
Ensuite une fois que çà c'est fait, il y a effectivement de nombreuse optimisation à faire. Simplement on va avoir du mal à te conseiller sans avoir un aperçus plus complet.
Tes ministères sont cependant un parfait exemple d'optimisation à faire. La mise en place d'un index sur l'identifiant du ministère permettra surement d'aller plus vite qu'avec tes 10 tables. Sans compter que ce sera plus propre au niveau de tes requêtes SQL.
Bref tu arrives effectivement comme l'a dit Keke à un moment ou tu te rend compte qu'il va falloir refaire certaine chose, car tu n'étais même pas conscient des problèmes que çà pouvais éventuellement causer.
Ton histoire de 40 tables c'est notamment un trucs à revoir une page ne doit pas faire trop de requêtes à la bdd si elle veut arriver vite.
En tout cas je te conseille de faire attention, il y a plein d'erreur sournoise, qui peuvent t'handicaper pendant longtemps. On est nombreux à se rendre compte de problème en phase de production et à ne plus savoir ou donner de la tête entre le désir d'évolution, l'administration de la communauté et la stabilité de l'application qui est de plus en plus difficile au fur et à mesure des ajouts.
J'espère juste pour toi que tu seras en éviter plus que ce que d'autre on pu se prendre en pleine face...
http://dev.mysql.com/doc/refman/5.0/fr/c...ables.html
Donc en gros MYSQL stockant ses tables dans des fichiers risque de prendre plus de temps à trouver la table en question dans le dossier avant de commencer à chercher.
Et il y a sans doutes des méthodes pour limiter le nombre de table, on peut faire du réalisme sans pour autant avoir énormément de table.
Pose toi aussi la question de ce qui est fixe et de qui ne l'est pas! Es tu sur que certaine donnée n'ont pas à être dans des fichiers de configuration?
Pour savoir si une donnée doit être dans un fichier plutôt qu'une bdd:
- on regarde le nombre de donnée si il y en a ou y aura peut être plus de 100 la réponse est: table
- on regarde si les modifications fréquentes sont nécessaire (modif par tous les users plusieurs fois par jour) si c'est ou sera peut être fréquent la réponse est: table
- on regarde si l'on va avoir besoin d'obtenir une donnée autrement que par la seul clef si c'est ou sera peut etre le cas la réponse est: table
Dans les autres cas il peut être envisager de passer en fichier et d'éviter la lourdeur de l'appel à Mysql. J'ai mis en gras pour bien faire comprendre qu'il faut avant penser à l'évolutivité du script...
Ensuite une fois que çà c'est fait, il y a effectivement de nombreuse optimisation à faire. Simplement on va avoir du mal à te conseiller sans avoir un aperçus plus complet.
Tes ministères sont cependant un parfait exemple d'optimisation à faire. La mise en place d'un index sur l'identifiant du ministère permettra surement d'aller plus vite qu'avec tes 10 tables. Sans compter que ce sera plus propre au niveau de tes requêtes SQL.
Bref tu arrives effectivement comme l'a dit Keke à un moment ou tu te rend compte qu'il va falloir refaire certaine chose, car tu n'étais même pas conscient des problèmes que çà pouvais éventuellement causer.
Ton histoire de 40 tables c'est notamment un trucs à revoir une page ne doit pas faire trop de requêtes à la bdd si elle veut arriver vite.
En tout cas je te conseille de faire attention, il y a plein d'erreur sournoise, qui peuvent t'handicaper pendant longtemps. On est nombreux à se rendre compte de problème en phase de production et à ne plus savoir ou donner de la tête entre le désir d'évolution, l'administration de la communauté et la stabilité de l'application qui est de plus en plus difficile au fur et à mesure des ajouts.
J'espère juste pour toi que tu seras en éviter plus que ce que d'autre on pu se prendre en pleine face...