15-05-2010, 12:42 AM
Quand tu dis beaucoup d'enregistrements tu penses à combien ? milliers, centaines de milliers, millions, dizaines de millions ? Sans pouvoir donner un chiffre exact tu devrais quand même pouvoir donner un ordre de grandeur.
Je pense que dans tous les cas il faut que tu partes sur une seule table rapports. À chaque entité sa table. Pas la peine d'avoir plusieurs tables "doublons", c'est pas logique et ça va te compliquer la vie pour rien. Puis est-ce que t'as besoin de conserver tous les rapports, même ceux qui sont vieux de plusieurs semaines / mois / années, ou des purges sont-elles envisageables ? Si t'en as besoin ad vitam eternam, peux-tu envisager de déplacer les données dans une table "archives" ?
Garde une seule table, je pense pas que arrives aux limites de MySQL, qui est très costaud est très à l'aise avec des tables de plusieurs millions d'enregistrements, pourvu que les requêtes tirent parti des bons index de la table. Faire des jointures ne changera rien, si tu déportes des données dans d'autres tables et que tu te retrouves avec des tables de relation 1:1, le même nombre d'enregistrement sera parcouru mais tu auras des ouvertures de fichiers en plus par rapport à une structure avec une table. Et si tu crées une table par type de rapport par exemple, je suis pas sûr que tu y gagnes de la performance par rapport au schéma traditionnel avec de bons index. Et si jamais le problème de volumétrie devait se poser un jour, c'est un "problème de riche". Tu optimiseras ton application à ce moment-là, mais inutile de chercher à sur-optimiser son appli pour des problèmes qui n'existent pas, ça va 1° te faire perdre du temps, 2° potentiellement créer de nouveaux problèmes, voire avoir l'effet l'inverse, 3° être inutile parce que le besoin n'existera (peut-être) jamais
Je pense que dans tous les cas il faut que tu partes sur une seule table rapports. À chaque entité sa table. Pas la peine d'avoir plusieurs tables "doublons", c'est pas logique et ça va te compliquer la vie pour rien. Puis est-ce que t'as besoin de conserver tous les rapports, même ceux qui sont vieux de plusieurs semaines / mois / années, ou des purges sont-elles envisageables ? Si t'en as besoin ad vitam eternam, peux-tu envisager de déplacer les données dans une table "archives" ?
Garde une seule table, je pense pas que arrives aux limites de MySQL, qui est très costaud est très à l'aise avec des tables de plusieurs millions d'enregistrements, pourvu que les requêtes tirent parti des bons index de la table. Faire des jointures ne changera rien, si tu déportes des données dans d'autres tables et que tu te retrouves avec des tables de relation 1:1, le même nombre d'enregistrement sera parcouru mais tu auras des ouvertures de fichiers en plus par rapport à une structure avec une table. Et si tu crées une table par type de rapport par exemple, je suis pas sûr que tu y gagnes de la performance par rapport au schéma traditionnel avec de bons index. Et si jamais le problème de volumétrie devait se poser un jour, c'est un "problème de riche". Tu optimiseras ton application à ce moment-là, mais inutile de chercher à sur-optimiser son appli pour des problèmes qui n'existent pas, ça va 1° te faire perdre du temps, 2° potentiellement créer de nouveaux problèmes, voire avoir l'effet l'inverse, 3° être inutile parce que le besoin n'existera (peut-être) jamais