Une solution simple et qui fonctionne, c'est de rajouter un attribut «id_cours» ou quelque chose dans le genre à chacune des 80 tables, et de le rajouter dans la liste des attributs de la clef primaire.
Ça veut aussi dire qu'il faut modifier les clefs étrangères... C'est du boulot, mais c'est étrange que le logiciel utilise autant de tables. Le travaille d'un SGBD, c'est de gérer des données, même quand il y en a des millions.
Le fait de rajouter l'attribut dans la clef primaire va faire organiser la base de données en fonction de l'attribut par le SGBD. Il va aussi construire des index.
Si cela ne suffit pas, même si ça parait étrange (c'est juste des cours, il y en a pas des dizaines de millions), tu peut regarder du cotés du partitionnement : http://fr.wikipedia.org/wiki/Partition_(base_de_données)
Les données vont êtres organisées sur les disques en fonction de critères que tu définis, pour que ça aille encore plus vite (par exemple, chaque établissement a son disque dur).
# Logiciel à améliorer
Posté par yellowiscool . En réponse au message Gérer *beaucoup* (vraiment !) de bases MySQL. Évalué à 4.
Ça veut aussi dire qu'il faut modifier les clefs étrangères... C'est du boulot, mais c'est étrange que le logiciel utilise autant de tables. Le travaille d'un SGBD, c'est de gérer des données, même quand il y en a des millions.
Le fait de rajouter l'attribut dans la clef primaire va faire organiser la base de données en fonction de l'attribut par le SGBD. Il va aussi construire des index.
Si cela ne suffit pas, même si ça parait étrange (c'est juste des cours, il y en a pas des dizaines de millions), tu peut regarder du cotés du partitionnement : http://fr.wikipedia.org/wiki/Partition_(base_de_données)
Les données vont êtres organisées sur les disques en fonction de critères que tu définis, pour que ça aille encore plus vite (par exemple, chaque établissement a son disque dur).
Envoyé depuis mon lapin.