Les concepteurs on pris le parti de partitionner les données en créant des tables ou des bases au choix.
L'inconvénient est clair pour tout traitement de consolidation, mais aussi dans l'impossible passage à l'échelle tant pour des raisons de ressources que pour des raisons d'administration.
Techniquement, il est plus coûteux d'effectuer dans la même seconde 10 (ou 100 ou 1000) recherches sur 10 (100, 1000) tables différentes que les mêmes recherches sur la même table. En effet dans un cas, on accèdera à des indexs différents (et des tables différentes) donc pas d'utilisation des différents niveaux de cache (de celui du processeur à celui du disque en passant par ceux du système) alors que des recherches sur les mêmes tables via les mêmes indexs utiliseront ces caches.
je ne me souviens pas si Mysql sait partitionner les tables ; c'est peut être la raison qui a amené à ce choix.
Mais c'est clairement une mauvaise solution. Si encore le niveau de "partitionnement" retenu avait été l'établissement ou à défaut le prof. mais la ! (pourquoi pas par élève ? :))
Au final s'il ne peut être question de corriger l'application, la meilleure solution est probablement celle de la multiplication des bases, car elle permet de plus facilement gérer des sauvegardes, restauration, administration en général pour chaque cours.
Mais il faut prévoir l'outillage d'automatisation pour ne voire qu"une base en administration courante, sinon c'est l'enfer.
Ensuite, attention sur toutes les solutions de scalabilité à base de multiplication d'instance Mysql (ou autre) ; c'est vite lourd à gérer.
Sinon, pour le dimensionnement, je pense que la meilleur solution c'est de monter un prototype et de tester les deux solutions aux limites d'exploitation prévue.
Au passage y a t'il un utilitaire pour basculer d'un modèle à l'autre en cas de changement de choix en cours de route ? Parce que sinon, il y a de gros risque d'avoir à se l'écrire après s'être fourvoyé dans la mauvaise direction.
[^] # Re: Merci !
Posté par bertrand . En réponse au message Gérer *beaucoup* (vraiment !) de bases MySQL. Évalué à 1.
Les concepteurs on pris le parti de partitionner les données en créant des tables ou des bases au choix.
L'inconvénient est clair pour tout traitement de consolidation, mais aussi dans l'impossible passage à l'échelle tant pour des raisons de ressources que pour des raisons d'administration.
Techniquement, il est plus coûteux d'effectuer dans la même seconde 10 (ou 100 ou 1000) recherches sur 10 (100, 1000) tables différentes que les mêmes recherches sur la même table. En effet dans un cas, on accèdera à des indexs différents (et des tables différentes) donc pas d'utilisation des différents niveaux de cache (de celui du processeur à celui du disque en passant par ceux du système) alors que des recherches sur les mêmes tables via les mêmes indexs utiliseront ces caches.
je ne me souviens pas si Mysql sait partitionner les tables ; c'est peut être la raison qui a amené à ce choix.
Mais c'est clairement une mauvaise solution. Si encore le niveau de "partitionnement" retenu avait été l'établissement ou à défaut le prof. mais la ! (pourquoi pas par élève ? :))
Au final s'il ne peut être question de corriger l'application, la meilleure solution est probablement celle de la multiplication des bases, car elle permet de plus facilement gérer des sauvegardes, restauration, administration en général pour chaque cours.
Mais il faut prévoir l'outillage d'automatisation pour ne voire qu"une base en administration courante, sinon c'est l'enfer.
Ensuite, attention sur toutes les solutions de scalabilité à base de multiplication d'instance Mysql (ou autre) ; c'est vite lourd à gérer.
Sinon, pour le dimensionnement, je pense que la meilleur solution c'est de monter un prototype et de tester les deux solutions aux limites d'exploitation prévue.
Au passage y a t'il un utilitaire pour basculer d'un modèle à l'autre en cas de changement de choix en cours de route ? Parce que sinon, il y a de gros risque d'avoir à se l'écrire après s'être fourvoyé dans la mauvaise direction.