je suis désolé je n'ai pas vu ton dernier message donc mon dernier message ne répond pas complètement à ta question mais le dernier intervenant l'a déjà fait.et lorsque qu'un message est rajouté à ce topic (sujet ?) il faut détruite toutes les lignes ayant l'id_topic pour que de nouveau il soit 'à lire' ?
bon :
je crée une table topic_lu ( champs : id, id_topic, idmembre)
lorsqu'un membre accède au forum, je liste les topics et avec une requete 'JOIN' je recherche les éventuels enregistrement ds la table topic_lu ; quand il n'y a pas de correspondance entre l'id_topic de la table topic (qui est la tables sujets chez moi) et de la table topic_lu pour cet id_topic et l'idmembre du membre connecté alors c que le topic contient un (au moins) message non lu
quand le membre ouvre ce topic et donc lit les message qu'il contient, je crée ds la table l'enregistrement => 'id_topic, idmembre'.
quand un utilisateur lambda rajoute un message à un topic :
- je supprime toutes les lignes de la table topic_lu qui ont l'idtopic de ce topic pour obligé le site à le donner comme à lire aux autres membres)
- j'ajoute l'enregistrement 'id_topic, idmembre' de ce membre lambda dans la table 'topic_lu' afin que ça ne soit pas un topic 'à lire' pour ce membre lambda, vu que c lui qu'il l'aura alimenté. (et je fais même pareil à la création d'un topic, afin que le créateur d'un topic n'ait pas ds sa liste 'nouveau message' ce topic).
Mais bon.... je vois pas bien ou est et à koi sert alors ma table associative (auquel je ne comprends pas grand chose)
malgré tout... suis je sur la bonne voie ?...
Merci de l'aide o)
la communauté d'entraide francophone dédiée au PHP
[RESOLU] forum : comment repérer pour un user les messages non lus ?
Merci pour cette explication claire.
je comprends l'intérêt ds mon cas d'utiliser ce type de fonctionnement
Mais alors, parlons code :
Cette requête pour sélectionner les 'messages non lu' d'un utilisateur est elle la bonne ?
SELECT idmessage, texte
FROM messages
JOIN messages-user
ON messages.idmessage = messages-user.idmessage
WHERE idmembre = '$un-id-de-membre' AND messages-user.lu = '0'
Merci
je comprends l'intérêt ds mon cas d'utiliser ce type de fonctionnement
Mais alors, parlons code :
Cette requête pour sélectionner les 'messages non lu' d'un utilisateur est elle la bonne ?
SELECT idmessage, texte
FROM messages
JOIN messages-user
ON messages.idmessage = messages-user.idmessage
WHERE idmembre = '$un-id-de-membre' AND messages-user.lu = '0'
Merci
dans la table messages-user tu n'as plus besoin du champ lu car cette table contient tous les messages lus.
avec une requête imbriqée, tu vas selectionner tous les messages de la table messages qui n'ont aucune correspondance dans la table messages-user:Cette requête pour sélectionner les 'messages non lu' d'un utilisateur est elle la bonne ?
SELECT * FROM messages WHERE idmessage NOT IN (SELECT idmessage FROM messages-user)
SELECT me.idmessage, me.texte
FROM messages me
LEFT JOIN messages-user mu ON me.idmessage = mu.idmessage
WHERE mu.idmessage IS NULL OR mu.idmessage=''
AND me.idmembre = '$un-id-de-membre'
ah oui en effet, je dois chercher les messages qui n'ont pas de correspondance ds la table associative.
ok ça me va parfaitement.
j'ai créé la table associative, 3 fonctions (AjoutLu, RetireLu et IsLu) et mis les appels à ces fonctions où il le fallait. ça fonctionne. Et enfin avec cette dernière requête imbriquée je vais pouvoir sortir la liste des messages à lire pour l'utilisateur lamda.
Tout ce que je voulais
merci bcp pour cette aide messieurs, je peux cliquer sur 'RESOLU'
Stève
ok ça me va parfaitement.
j'ai créé la table associative, 3 fonctions (AjoutLu, RetireLu et IsLu) et mis les appels à ces fonctions où il le fallait. ça fonctionne. Et enfin avec cette dernière requête imbriquée je vais pouvoir sortir la liste des messages à lire pour l'utilisateur lamda.
Tout ce que je voulais
merci bcp pour cette aide messieurs, je peux cliquer sur 'RESOLU'
Stève
Attention à la syntaxe de cette requête :SELECT me.idmessage, me.texte FROM messages me LEFT JOIN messages-user mu ON me.idmessage = mu.idmessage WHERE mu.idmessage IS NULL OR mu.idmessage='' AND me.idmembre = '$un-id-de-membre'
- l'opérateur AND est prioritaire sur le OR, du coup s'il n'y a pas de parenthèses autour, le moteur SQL retournera tous les résultats pour lesquels idmessage est null (quel que soit l'utilisateur) OU tous les idmessage vides pour le membre spécifié. Avec des parenthèse, on applique l'id du membre aux deux conditions :
( mu.idmessage IS NULL OR mu.idmessage='' ) AND me.idmembre = '$un-id-de-membre'
- en l'occurrence, le champ idmessage ne sera jamais vide. Soit il est null car par d'enregistrement trouvé dans la table, soit il est renseigné avec un id, donc on peut oublier le OU et les parenthèses
- à éviter également, les apostrophes autour des nombres. idmembre est certainement un champ numérique, du coup, pas d'apostrophes pour la valeur qu'on lui envoi :
me.idmembre = $un-id-de-membre
Ce n'est pas en améliorant la bougie que l'on a inventé l'ampoule...
En fait, la plupart des SGBD sont sensibles aux types des données. Dans un champ texte, ils attendent une chaine de caractères, dans un champ date ils attendent une date formatée, dans un champ numérique, ils attendent des nombres.
Les apostrophes en SQL servent à délimiter les chaînes de caractères (char, varchar, text, date, ...). Du coup, si tu mets un nombre entre apostrophe, le moteur de base de données peut considérer qu'il ne s'agit plus d'un nombre mais d'une chaine et considérer que ce format est incompatible par rapport au type de la colonne en base (pour une opération mathématique tu fais 2+3, pas '2'+'3')
Aujourd'hui certains SGBD comme MySQL ou MySQLi tolèrent cette syntaxe et font les conversions nécessaires aux mêmes. Mais du coup :
- le sgbd doit faire un travail de conversion supplémentaire (bon, ok, ça se compte en pouillème de millisecondes, mais c'est pas une raison)
- le jour où tu dois travailler sur oracle, sql server ou db2, tes requêtes ne fonctionneront plus et tu risques de passer un certain temps à t'arracher les cheveux avant de comprendre pourquoi (alors que tu peux prendre de bonnes habitudes des maintenant)
Les apostrophes en SQL servent à délimiter les chaînes de caractères (char, varchar, text, date, ...). Du coup, si tu mets un nombre entre apostrophe, le moteur de base de données peut considérer qu'il ne s'agit plus d'un nombre mais d'une chaine et considérer que ce format est incompatible par rapport au type de la colonne en base (pour une opération mathématique tu fais 2+3, pas '2'+'3'
)Aujourd'hui certains SGBD comme MySQL ou MySQLi tolèrent cette syntaxe et font les conversions nécessaires aux mêmes. Mais du coup :
- le sgbd doit faire un travail de conversion supplémentaire (bon, ok, ça se compte en pouillème de millisecondes, mais c'est pas une raison
) - le jour où tu dois travailler sur oracle, sql server ou db2, tes requêtes ne fonctionneront plus et tu risques de passer un certain temps à t'arracher les cheveux avant de comprendre pourquoi (alors que tu peux prendre de bonnes habitudes des maintenant
)Ce n'est pas en améliorant la bougie que l'on a inventé l'ampoule...