Problème de type dans une requête

[MS-DOS_1991]

Bonjour à tous

Je développe un forum et cherche en ce moment à coder la fonction qui permet à l'utilisateur de distinguer les forums lus de ceux qu'il n'a pas encore lu

J'ai réfléchi et ai trouvé (tout seul comme un grand ) la solution qui me paraît être la meilleure :

* Quand un visiteur visite un forum, on ajoute son id dans un champ f_read de la table forums (pareil pour les sujets)

-> Concrètement, ça donne :

UPDATE forums
                      SET f_read = f_read + ', 1'
                      WHERE f_id = 3

-> Ce qui donnera à terme quelque chose du genre f_read = '123, 54, 1, 2, 48, 87987, 654'

(bien entendu, dès qu'un membre poste dans le forum, je vide ce champ )

* Ensuite, pour lister les forums, on fait une condition qui regarde si l'id du membre est dans la liste :

SELECT [...] CASE WHEN 1 IN (f_read) THEN '1'
                                         ELSE                                    '0'
                                    END AS f_read

... et j'affiche mes belles icones lu / non lu

Seulement voilà, je fais directement appel au champ f_read dans ma requête (avec IN (f_read) ) et MySQL me renvoie toujours 0 même quand mon id est dans le champ

Je pense que c'est parce qu'il interprète mon champ comme du texte (et l'entoure donc avec des guillemets) et non comme une "suite de nombres séparés par des virgules" ...

En effet, la requête suivante marche parfaitement :

SELECT [...] CASE WHEN 1 IN (123, 54, 1, 2, 48, 87987, 654) THEN '1'
                                         ELSE                                    '0'
                                    END AS f_read

Ce qu'il faudrait, c'est covnertir le contenu du champ en un format de suite que MySQL comprendrait, mais je sèche...

Des idées ?

P.S: Arf, on a pas le droit à assez de smileys dans nos messages : P

Edit : Mes explications me semblent un peu confuses, n'hésitez donc pas à me poser des questions ^ ^

Modifié 4 Juillet 2006 par MS-DOS_1991

[Zodd]

Salut

Tu t'y prends mal,

plutôt que de faire un champ avec la liste des ID des utilisateurs (c'est complètement loufoque quand on connait un peut merise).

Tu dois créer une table à part pour celà!

Exemple

1. Table "Forum"

2. Table "Users"

et 3, table "ForumsLus"

ForumsLus est une table associative qui est automatiquement créée lors d'une relation 0-N <-> 0-N

En francais : Si pour un utilisateur il peut y avoir plusieurs forums lus, et qu'un forum peut être lu par plusieurs utilisateurs, il faut d'office une table supplémentaire pour normaliser ta base de données et faire l'association entre les 2.

La table ForumsLus comporte 2 clés étrangères, un id_user et un id_forum (ce qui fait l'association) + son propre id (id_forumlu) ce qui fait 3 champs.

Ensuite pour voir si un utilisateur a lu le forum ou non, la requête SQL aura à peut près cette gueule :

$q="SELECT COUNT(*) AS estLu
FROM  ForumsLus
WHERE
	ForumsLus.id_user=" . $id_user . " AND
	ForumsLus.id_forum=" . $id_forum . "
";

Si EstLu = 1 alors le forum est lu, sinon n'est pas lu.

Zodd

P.S.: à toi aussi de faire en sorte qu'il n'y ait pas 2 fois la même assocation dans la table "ForumsLus", de un ça serait complètement inutile, et de 2 cela nuirait au performances de la requête SQL suivant le nombre d'enregistrements. (Voir : Contraintes d'intégrités référencielle)

Modifié 1 Août 2006 par Zodd

[MS-DOS_1991]

Merci de ta réponse complète, je regarde cette solution

[Zodd]

Merci de ta réponse complète, je regarde cette solution

De rien,

j'ajouterais ceci :

Dans la table ForumLus, tu pourrais éventuellement ajouter un champ "DateDerniereLecture" (un peu long le nom mais c'est pour être explicite). Qui prendrait comme valeur la date et l'heure de derniere lecture de tel forum par tel utilisateur. Et en comparant la date du dernier post par exemple, le marquer comme Lu si la date du dernier post est inférieure à "DateDerniereLecture" ou non-Lu dans le cas contraire.

Cela éviterait notament de devoir faire des DELETE et des INSERT à répétition dans cette table. Un simple update du champ "DateDerniereLecture" suffirait, et cela serait bien mieux niveau perfs.

Zodd

Modifié 1 Août 2006 par Zodd