Reprise du message précédent :

 
Genre ça ?  
 

 
En fait, j'utilise ce fichier pour que l'admin gère la liste des smileys et leur code.
Chaque couple de lignes contient le fichier image et le code du smiley. (j'aurais pu faire ça joliment en XML mais trop chiant de mettre les balises pour un truc aussi simple ).
Donc si l'admin veut rajouter, supprimer ou changer l'ordre d'affichage des smileys, il édite ce fichier et valide et ça met tuot ce qui faut dans une table de la BD pour être réutilisé dans les messages.
Je pourrais faire une jolie interface pour manipuler ce fichier mais c'est tellement simple de prendre un éditeur de texte que ça urge vraiment pas.

Dites... Comment vous gérez les résultats des recherches ? (ne serait-ce que la liste des nouveaux messages)
 
Je pense notamment à l'affichage sur plusieurs pages des résultats.
La liste des résultats est susceptible de changer entre le moment où l'on affiche la première page et disons si l'on va sur la page 2 puis qu'on revient à la page 1.
 
Déjà je me demande s'il est judicieux de refaire la requête à chaque changement de page avec juste le LIMIT qui change. D'une part parce qu'une recherche c'est lourd et d'autre part, pour ce que je mentionne plus haut : la liste est très changeante et on risque de paumer des résultats qui passeraient d'une page à l'autre.
 
J'envisage donc de stocker les résultats d'une recherche dans une table faite pour ça et de supprimer les recherches qui datent de plus de n heures avant chaque nouvelle recherche.
 
Est-ce comme ça qu'il "faut" faire ?
 
 
Je pense à faire 2 tables :
RECHERCHE :
- id (clé primaire)
- idmembre (membre qui a fait la recherche)
- date (moment où on a lancé la requête)
- type (recherche par topic ou par message)
 
RESULTAT :
- id (clé primaire, je peux même m'en passer et faire une clé à partir des 2 premiers champs suivants pour économiser 4 octets par résultat)
- idrecherche (id de la recherche à laquelle correspond la ligne de résultat)
- ordre (position de la ligne dans les résultats, afin de les afficher page par page avec un BETWEEN )
- idtopic (ou idmessage suivant si on veut un résultat par topic ou par message)

le problème avec ce que tu dis, c'est que ça va emmerder l'utilisateur.
 
parce que si il fait page 1 - page 2 - page 1 et que les résultats changent, merci la logique.

 
Bah non justement c'est pour éviter ce problème qu'il demandait ça...
 
Enfin je crois

Sur le mien, je stocke le resultat de la recherche. En gros, la recherche est conservée durant une durée determinée. Tant que l'utilisateur navigue sur les resultats, la durée se met à jour. Il a donc la possibilité de consulter une ancienne recherche, de relancer une recherche avec les mêmes critères.
Du coup, c'est plus souple et cohérent pour lui. Et c'est plus tranquille pour le serveur sur le traitement. Par contre, ca demande plus d'espace de stockage.

 
 
Donc sur le fond c'est faisable mais y'a plus pratique et plus élégant disons  

Je dis justement le contraire.
 

Ouf qq1 m'a compris.
idem pour cinocks qui confirme ce que je pensais.

ca tombe bien ta question, je suis en train de voir pour les MP
 
Pour moi j'utilise la meme structure pour les sujets et les reponses, sauf que pour le sujet je rajouter des cases, ainsi que pour la table membre et creation de la table "ignore list".
 
sujet_priv, je rajoute:
 
-supp_auteur
-supp_destinataire  (si les deux supprime le topic j'efface de la bdd, sinon je ferme seulement).
-id_destinataire(ou pseudo_destinataire, je verais plus tard le plus optimisé et pratique).
-lu_auteur
-lu_destinataire
-avertissement_mail_auteur
-avertissement_mail_destinataire
 
table membre, je rajoute:
 
-nb_total_mp
-nb_new_mp
 
 
table des reponses, je ne rajoute rien.
 
Bien evidement, plus besoin de gerer la table des drapeau, je le fait avec les cases "lu".
 

ok, j'avais mal compris.
 
N'empêches que certains le forums fonctionnent comme ça et que c'est très lourd, la recherche qui change.

Oui je suis bien d'accord.
C'était justement en vue de corriger ce problème que j'envisageais ça et je me demandais juste si c'était une solution déjà rencontrée ailleurs (ce qui me permettait de valider l'idée)

c'est peut être justement parce que je me préoccupe de l'espace que ca tourne vite

encore une fois c'est pas une question de place, mais une question de quantité de donnée rapatriée à chaque rapatriement de posts

ben l'espace depend du nombre de message non? ca veut dire que quand hfr aura 2 x plus de message, ca va ramer ?
 

Non, et ca s'appelle la complexité

la complexité de quoi ?        

http://fr.wikipedia.org/wiki/Compl [...] orithmique

Voila. En gros, ce qui coute surtout en temps, ce sont les acès disque. Devoir rapratrier des donées pré-formatées de la BDD est beaucoup pluss couteux en terme de temps disque que faire le parsing à l'affichage sur les données brutes que tu aura récupéré en BDD. Ce, d'autant plus si tes membres utilisent à fond les BBcodes et les smilies ...

donc en résumé ca coute plus si le message est plus gros ? ce qui coute plus c'est que le message html est plus long que le message avec les code ubb ?

Oui, message beaucoup plus long = beaucoup plus de données en base = plus de données à rappatrier = l'appli ralentit si on est limité par l'IO des disques durs (et c'est souvent le cas)

= Plus souvent du cache miss en bonus

voila
Donc ecrivez en style SMS
Ou alors tu convertis chaque post en image, et tu mets dans la db uniquement un lien vers l'image

Et pour éditer les messages, tu codes un OCR.

exactement
n'empeche pour les disques ca serait royal
 
(ceci dit pour l'edit tu pourrais stocker le message d'origine en texte dans une table a part).
 
Par contre ca ferait taffer les disques des fronts et le pauvre apache

Ouais enfin les images, il faut les lire et les envoyer quand même.

ouais, enfin je suis pas sur que la taille de l'image soit plus petite que la taille du texte, donc tu auras toujours tes accès disque, mais pas au niveau de la DB, au niveau d'apache

c'est un detail ca

j'ai edite entre temps

Ben bof, c'est ton serveur web et ta BP qui en mangent plein la yeule derrière vu qu'il faut 1. générer et 2. servir toutes tes images

J'ai une idee : tu mets le lien vers un fichier texte sur le front dans la DB

Cool, y a plus grillé que moi

j'ai edite j'ai dis

I don't care

tu gzip le texte avant de le mettre en base aussi

c'est pas con ca par contre.
ca serait sympa de pouvoir passer directement le truc compresse au navigateur et qu'il se demerde avec.

ouais mais pour la recherche instra topic, ca risque d'etre tendu si il faut dezipper tous les messages
(Mais si la recherche se fait sur une table d'index, il n'y a pas de probleme, c'est ca ?   )

la recherche se fait sur une table a part, c'est pas un soucis

ce qui signifie utiliser du js et c'est pas tres bon pour le referencement et pour les gens qui ne l'utilisent pas le js.
 
Mais bon la compression/decompression, c'est assez lourd non?

Vite il faut que je brevette ça

breuveter la compression de texte ?
 

non la feature de compression de texte dans une bdd pour l'utilisation dans un forum de discution