Utiliser les sessions pour le nombre de commentaire de chaque article ?

Bonjour à tous, premier post sur le forum

Je souhaiterais savoir si vous pensez que mettre le nombre de commentaires de chaque articles sur mon site dans des variables sessions est une bonne idée ? Au bout de 200 articles le chargement sera très long non ? Merci d'avance.

Quel intérêt de stocker ça en session ? Les sessions sont faites pour stocker des infos propres à l'utilisateur, pas des trucs communs à tous (qui ont toute leur place en BDD ou en cache serveur).

Il faudra qu'un m'explique les deux "-1" sur la question de l'OP…

Oui .... Il n'y que des membres du sdz ici lol Enfin bref j'ai essayé de faire cela :

1
2
3
4
5
6
7
8
9

// Si tout va bien, on peut continuer
// lancement de la requete
$sql = 'INSERT INTO nbr_commentaire (id, nbr) VALUES ( \'\', \'$nbr_com\' )';

// on insere le tuple (mysql_query) et au cas où, on écrira un petit message d'erreur si la requête ne se passe pas bien (or die)
mysql_query ($sql) or die ('Erreur SQL !'.$sql.'<br />'.mysql_error());

// on ferme la connexion à la base
mysql_close();

Mais je reçois cette erreur : Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING in /home/u146006879/public_html/ckeditors/une-date-de-sortie.php on line 172

A chaque fois qu'un visiteur ajoute un commentaire, tu insères le commentaire en base avec un

1

INSERT INTO commentaires(...) VALUES(...)

Lorsque tu veux afficher le nombre de commentaires d'un articles tu fais un

1

SELECT COUNT(id) FROM commentaires WHERE id = $id

Merci j'ai réussi d'une autre manière car chez moi le count me renvoyer absolument rien. Pendant 1 semaine … Donc finalement a chaque fois que une page avec une news est lancé je fait un mise a jour du nombre de commentaire grâce à un delete puis insert cocatene.

Wrong ! Une telle requête n'est pas envisageable, car demadeuse de pas mal de ressources. Autant mettre en place une politique de caching en mettant ce genre de valeurs (un compte) dans la table principale (ici celle concernée par les commentaires).

Et faire une sous-table pour l'insertion du nombres de commentaires… c'est encore pire (faire une jointure pour une telle donnée ? Quel est le sens de cette table, qui peut être intégrée dans le modèle principal ?

Et le combo DELETE + INSERT est pas beaucoup mieux.

Autant apprendre les jointures pour récupérer toutes les infos en une seule requête : une fois optimisé la consommation de ressources sera bien moindre et les données sont forcément à jour sans avoir à la stocker en cache (et donc la modifier régulièrement).

Oui et non… Les jointures ne sont pas la réponse à tout ! Des fois, faut mieux deux petites requête (ici : selection des données et des meta de l'objet à commenter et ce qui s'y rapporte : jointure d(es) auteur(s), … et une autre sélection des commentaires, avec leur propre méta données et la condition qui va bien)