30-07-2009, 10:24 AM
(30-07-2009, 10:07 AM)IGstaff a écrit : Sephi-Chan, c'est une question ennuteyuse en effet car il y a très peu d'autres alternatives.
Je reviens d'abord sur celle la.
MySQL est fait pour pouvoir gérer des millions d'entrées, ce n'est que eu genant.
Ceci dit plusieurs tables comme celle là provoquerait soit un ralentissement du au proc, soit du à la RAM qui surcharge.
Mais globalement, le nombre d'entrées influence beaucoup moins la vitesse d'exécution de la requete qu'on ne pourrait le penser.
J'ai pu voir ça au boulot, la recherche sur de grosses tables n'est pas un problème, si les colonnes qui servent aux conditions sont indexées (donc en l'occurrence, même la date pourrait être indexée, pas seulement les foreign keys).
Le plus coûteux n'est pas tant la recherche, mais plutôt la création d'un sujet : cela créer une entrée dans la table de relation pour chaque utilisateur (donc beaucoup).
Quand un nouveau message est posté dans la discussion, c'est tout bête : on met simplement à jour la date de dernière activité de la discussion. De même, une fois qu'une utilisateur a lu une discussion, on change la date de dernière visualisation dans sa relation avec le sujet (phrase douteuse…).
Non vraiment, ce qui m'inquiète, c'est l'insertion massive et soudaine dès qu'on crée un sujet : est-ce que la base sera ralentie (si oui, dans quelle mesure et pour combien de temps ?) quand on lui demandera d'insérer 2000 entrées d'un coup ?
Si oui, alors faire en sorte de ne renseigner cette table que pour les utilisateurs qui ont été actifs récemment sera nécessaire, mais l'idéale serait de se passer de cette restriction (dans une optique d'exactitude des données). Les entrées vieilles d'un certain nombre de jours seront effacées régulièrement : si la personne n'a pas été voir le sujet, c'est que ça ne l'intéresse pas.
Sephi-Chan