Discussion :

[psychoBob]

Bonjour,

Je bute sur un problème pour mon forum :
Jusqu'ici je classais les nouveaux sujets par id décroissant (c'est plus rapide que par la date), le dernier se plaçant en haut de la liste, comme sur tous les forums.

Maintenant je veux que lorsqu'un sujet reçoit une réponse, ce sujet reviennent en haut de la liste même si d'autres sont plus récents, comme sur tous les forums aussi.

Donc j'ai placé un champ 'derniereRep' dans la table 'sujet', qui est updaté à chaque nouvelle réponse.

C'est facile maintenant de classer les sujets selon l'ordre de leur dernière réponse.

Oui mais le tout dernier sujet doit se placer en haut de la liste, même si il n'a pas eu encore de réponse.


Alors là vraiment je m'embrouille un peu ! Si vous avez l'expérience de ce genre de trucs, je veux bien la recette.


Merci d'avance.


**edit**

Je vois bien une recette un peu lourde :
je crée un champ 'idNew' .
A chaque nouveau sujet, je selectionne le MAX idNew et je l'incrémente de 1.
Idem pour chaque nouvelle réponse.
Et puis je fais un order by idNew.

ça devrait fonctionner qu'en pensez-vous ?

[Mr N.]

classe par date de mise à jour, sachant que cette date est mise à jour dès qu'une réponse y est postée.

[psychoBob]

Merci pour ta réponse Mister N

A moins d'avoir mal compris celle-ci, c'est ce que j'ai dit que je compte faire.
Mais ça ne résoud pas le problème posé :

Le dernier sujet n'a pas de réponse, donc rien dans la table mise à jour :
Comment fais-tu dans ce cas pour le placer en haut de la liste et pour ensuite classer ceux avec des réponses selon leur date de mise à jour ?
Idem si il y a plusieurs nouveaux sujets, ils doivent se classer les uns derrrière les autres, en attendant qu'un sujet avec une mise à jour les devance.


**edit** donc je pense à cela, comme dans mon précédent edit :

Je crée un champ newId dans la table sujet.
A chaque nouveau sujet ou chaque nouvelle réponse, je sélectionne le MAX de newId parmi tous les sujets ayant la même clef étrangère (idSujet).
Là je l'incrémente de 1.
En cas de suppression à postériori d'un message, je le décrémente de 1.

A priori je ne vois pas de bug en vu, et vous ? Si deux tuples ont le même newId suite à une décrémentation, que va-'il se passer ?

[Mr N.]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
1    01/01/2006    20     02/01/2006      'Sujet #1 créé le 1 janvier, date de mise a jour = date dernière reponse (#20) : 2 janvier'
2    03/01/2006    -1     03/01/2006      'Sujet #2 créé le 3 janvier, date de mise à jour = date de creation car pas de réponse  (#-1) : 3 janvier'

[psychoBob]

A oui,

tu veux dire que je crée un 'champ mise à jour'.

Par défaut celui-ci est incrémenté lors de sa création avec la même date que le champ 'date de création'.

Ensuite on update à chaque mise à jour.

Si j'en supprime un, je vais chercher la date de la dernière réponse pour ce sujet et je l'insère à la place de celle du tuple supprimé.


C'est cela ? je suis un surdoué ?

[Mr N.]

C'est cela ?

Oui. C'est juste une proposition, il y a surement d'autres soluces, toutes les unes plus ou moins propres que les autres

je suis un surdoué ?

Non. Tu n'aurais pas besoin d'être sur ce forum

[psychoBob]

Disons que j'aurais voulu éviter un ORDER BY sur la date, ça doit être assez long à classer, surtout par rapport à un classement sur des ID.

Vous en pensez quoi ?

[Mr N.]

Ben je pense que déjà ta colonne doit être de type "date" (ou equivalent).
Ensuite je sais pas si elle doit être indexée, si oui tes tables doivent être "analyzer" pour des perfs optimales. Un "explain" de la requete est fort utile pour ça.

Ensuite avec un petit cache maison ca devrait booster.

[psychoBob]

Je n'ai rien compris à analyser, cache et explain...

C'est très utile ces engins là ? Histoire de me motiver pour plonger dans un tuto, le cas échéant.

[Mr N.]

ANALYZE TABLE est très très ... très utile à partir du moment ou tu fais des jointures. Je ne sais pas l'impact sur un simple order by.
EXPLAIN est très très ... très utile pour savoir comment le moteur de mysql va planifier l'execution de la requete surtout pour des jointures. Ceci permet de savoir si des index sont bien placés.

cache, ben quand tu regardes le nombre de lecture d'un sujet / nombre de réponse/édition, tu te dis vite que d'une lecture à une autre, pas beaucoup de chose n'ont changé, et qu'il est inutile de refaire une requète sql. Il suffit de renvoyer le résultat de la dernière lecture, et ce jusqu'à la prochaine modif (new/update/delete)

[psychoBob]

ç'est compliqué à gérer le cache ?

[Mr N.]

Algo simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
Si le cache correspondant à l'url demandée n'existe pas alors
   générer la page comme d'hab tout en capturant le flux sortant
   stocker le flux sortant en fonction de l'url demandée dans un cache
   envoyer le flux vers le navigateur
sinon
   envoyer le contenu du cache vers le navigateur
finsi

Simple comme bonjour ou presque.
Le plus dur est d'effacer les caches quand il y a besoin. Pour ça le plus simple est de tout effacer, le mieux étant de n'effacer que ce qui est impacté.

Bref tu peux faire les choses très facilement est très simplement, ce sera toujours mieux que rien, mais tu peux aussi faire les choses très finement, en gèrant les headers http et tout et tout...

[psychoBob]

Ok merci Mr N,

Je vais approfondir la question.

ça va faire l'objet de nouveaux posts je crois...