Reprise du message précédent :
Oui mais non, tu peux demander à migrer sur un serveur avec mysql4 je suppose, suffit de cliquer sur un truc d'admin, c'est bien stable la version 4 hein... C'est juste qu'ils te migrent pas automatiquement

Oui c'est ce que j'avais fait, et du coup ça marche

La question à quatre francs six sous :
On peut faire la mise à jour de plusieurs entrées d'une même table en une seule requête ?
La même chose pour des ajouts ?

pour mettre à jour, il suffit que ta requête SQL est une clause Where assez "large" pour mettre à jour plusieurs champs.
Pour insert, pas à ma connaissance. Ca doit dépendre des SGBD après.

ne me tentes pas, n'oublie pas que j'ai toujours ma V2 en préparation
http://antibillou.free.fr/forumV2

sympa de te proposer

 
le code HTML est très propre, félicitations

 
+1 pour le code propre
Mais franchement, ta mise en page est super sympa. C'est différents des MD et phpBB  

yep, et puis il des temps de génération de ouff

Bof, ca passe pas le validateur : 14 erreurs.
Mais me suis bien marré.

A moins que je ne comprenne pas ce que tu veux dire, pour colorer le forum ou il y a un new message tu change juste le style css de la case correspondante suivant qu'elle est lu ou pas ...
 
Non ?

gernouille > En comparant la date du dernier message de la discution avec la date de derniére consultation de la discution par le visiteur (date que t'as pris soin de noter quelque part), je pense que tu devrais t'en sortir.

Alors on remonte au niveau conceptuel, un utilisateur peut lire 0 à n message, uun message peut etre lu par 0 à n utilisateur donc association lire devient entité lecture avec une clé message/user

Tu fais une requête en début de script et tu ponds un array en PHP.

Tu peux t'en sortir en une requette avec deux tables, une qui liste les discutions (date de dernier message de la discution à rajouter dans cette table) et une qui liste les dates de derniére lecture de chaque discution par chaque visiteur.
Et pour avoir la lsite des discution avec les dates à comparer, il suffit de faire une jointure à gauche (toutes les lignes de la table de gauche sont récupéré même s'il y a pas de ligne correspondant dans l'autre table)
 
Avec mysql, ca donne : SELECT patati FROM table1 LEFT OUTER JOIN table2 ON Id=TopicId WHERE ...

Ouai il me semble que pour afficher différentes couleurs, il te faut comparer à une date de visite de tes membres, donc un champs de plus dans ta table membre

 
je voulais savoir, dans la table post, est ce que vous stockez des informations sur l'auteur? (du genre signature, pseudo, etc...) ou simplement l'id du posteur puis a l'affichage vous faites une requête qui va chercher les infos sur l'auteur?
 
Je pense que c'est la deuxieme solution la + pratique et la meilleure... Mais j'ai un probleme avec mes boucles ca m'oblige à mettre une requete dans ma boucle d'affichage des posts, et je pense que ca ralentit pas mal l'affaire... non?
 
Comment vous vous y prenez?

Tiens par hasard il y en a qui se sont mis à utiliser les spécificité de mysql 4.1 voir même 5 ?
 
Genre (enfin pour mysql 5) les procédures stockées, les subrequets etc ?
 
Enfin joce je pense que oui mais les autres ?

Moi non.
 
Déjà que j'évite un max les jointures pour cause de bouffage énorme de ressource alors on verra plus tard pour ça.
 
Et puis en fait, je me suis rendu compte que chez moi, notemment le forum de ma femme, les requêtes SQL, ça bouffe que dalle en vitesse comparé au PHP, même sur des choses simples comme des boucles ou des trucs du genre.

 
Ah... oui je vois de quoi tu parles... même si c'est pour un site tant qu'à faire autant le faire à fond non?
 

 
Euh... tu répondais à moi ou à Je@nb??
 

Je répondais à Je@nb.
 
Pour répondre à ta question, perso, je charge toutes les infos de chaque membre en début d'affichage de page et je stocke.
Je pense que ce n'est pas la bonne méthode quand on a 300.000 membres, mais jusqu'à quelques milliers, ça fonctionne.

 
 
Ok !

D'autres techniques pour le stockage des infos du membre?

T'es sur d'avoir lu mon message jusqu'au bout? Par ce que là, j'ai vraiment l'impression d'avoir parlé dans le vide et quand j'aide sur un forum, j'aime pas avoir cette impression là.

les remplacement à faire :
patati par la liste des champs que t'as besoin de récupérer
table1 par le nom de la table des discutions
table2 par le nom de la table de derniére lecture de la discution
id et topic_id par les noms du champ de chaque table qui te permettent de relier les deux tables.
Et aprés le where tu rajoutes les conditions dont t'as besoin pour n'avoir que les discutions qui t'intéressent.
 
EDIT : J'avais mis en minuscule les éléments variables (noms de tables, de champs ...) et en majuscule la structure de la requette.

Moi, j('ai une table membre qui contient les infos du membre et dans les autres tables le seul élément du membre qui se balade, c'est l' id.
Imagine ce que ca donnerait si on se retrouve avec les infos éparpiller dans tous les messages. Un membre qui change d'adresse email ou qui la cache ou la montre et on devrait modifier tous les messages qu'il a posté dans toutes les sections du site? Et je parle pas au niveau espace de stockage, ca gonflerait énormément toutes les tables.
 
Personellement, je préfaire la simplicitéd'une jointure bien pensé. En plus les jointures sont trés rapide avec les bons index, Peut être même plus, je pense, que la récupération de l'intégralité d'une énorme table de membre. Du moins sur un forum comme ici, ca doit être sensible la différence.

Si tes tables s'apellent table1 et table2 alors oui.
Si elles s'apellent pas table1 et table2, il faut mettre les bons nom de table et ca sera comme il faut.
 
Pour le select * , ca prendra tous les champs de toutes les tables de la requette. (donc des deux tables dans celle ci) Si tu sais à l'avance que tu n'utilisera que certaines colones alors précise les. Ca permettra de rendre la discution PHP<=>MySql plus rapide vu qu'ils auront moins de données à s'échanger.

Aprés, tu fais comme d'habitude. C'est pas par ce que la requette envoyé à mysql est un peu plus évolué que la façon de récupérer les données sera différente.

 
Merci de la réponse
 
En effet je n'avais pas pu penser à cette technique là, puisque je n'y connais rien en jointures mysql
 
va falloir que je me documente là dessus...
 

cherche "max" et "group by" dans la doc de mysql. Attention, pour qu'une requette avec un group by soit valide, il faut que le group by contienne toutes les requettes qui ne sont pas des résultat de regroupement multi ligne (fonction tels que min(),max(),sum(),count(), ...)
Si t'as besoin, je te posterais une requette type, mais ca serait bien si t'arrivais à la créer tout seul.
 
 
Moi, j'ai opté pour le stockage de cette information dans la table des topics pour éviter justement de devoir la récupérer à chaque fois.Je sais bien qu'il faut théoriquement éviter le rajout de colone dont le résultat est recalculable à partir des autres colones, mais en pratique, c'est parfois nécessaire pour pas perdre trop de puissance machine.

C'est vrai qu'en plus des addslashes, quelques isnumeric, htmlentities et quelques autres fonctions du genre peuvent être utile. Mais attention à les utiliser à bon escient (un htmlentities sur un mot de passe ou un id numérique par exemple, c'est pas trés utile. )

moi oui depuis longtemps... ha, zut on parle de mysql, faut dire ils sont pas en avance...
spa mal aussi sqlite ...  

Avec la jointure à gauche (left outer join), t'as les deux en une requette et t'as une date dans la table des lu que s'il y a eu un lu. Si t'as pas encore lu la discution, ca retournera "null" (je sais plus quelle valeur ca prend niveau php)

petite precision:
le mot cle outer est inutile

Le htmlentities() ne sert à rien contre les injections SQL. Le seul intérêt c'est lors de l'affichage de données en HTML pour éviter les failles XSS (et htmlspecialchars() suffit)

euh, un mysql_real_escape_string serait pas plus approprié qu'une multiplication de fonction PHP ?

Je suis d'accord, c'est pour ça qu'il faut les utiliser à bon escient.

forum_topic.id , c'est un nombre unique? (chaque nombre de la colone ne peut pas être présent plusieurs fois dans cette colone)
En tout cas, si t'as le même post avec des id différents, ca voudrait dire (si je comprend bien) qu'il appartient à plusieurs discutions. Normal alors qu'il te le sorte pour plusieurs discutions.
 
Où alors j'ai pas compris comment fonctionnent tes tables les unes par rapport aux autres.

joce, si tu passes dans le coin, met un id sur le header d'hfr steplé

Zis ize ze power ov HFREnhance

oué ben t'as vu comment il fait hfrenhance pour ça ?