ben ik bezig met een forum maken, maar ik kom niet uit het volgende:
ik wil als er een nieuw bericht geplaatst wordt, en het lid heeft het nog niet gelezen, dat er dan ee sterretje komt. als het lid het bericht daan leest gaat het sterretje weer weg.
ik heb geen idee hoe ik dit moet doen. ik heb al meerdere manieren geprobeerd, maar het lukt niet. kan iemand mij helpen?
Je hebt voor de koppeltabel alleen maar nodig:
- message_id
- user_id
met een index op beide attributen (jammer dat een index-only table nog niet kan in MySQL) en zodra een gebruiker het bericht leest doe je een delete from koppeltabel where user_id=$user_id and message_id=message_id. Voor het tonen van de messages met bijvoorbeeld een sterretje of een andere kleur doe je een outer join met de message table of een where exists naar de koppeltabel.
van john d is wel een goede, maar als een lid het bericht niet leest blijft er altijd wat in de koppeltabel staan. dus kan je beter een opschoonsysteem toepassen van aad b. ik het allemaal
@ gnotrgnotr gnotrgnotr;
Nee dat kan dus niet, lees eens het topic door, en dan vooral dat van Karl en Niels...
Database...
Topic
- id
- user_id
- title
- message
- dateTime
User
- id
- username
- password
- name
Read
- id
- uesr_id
- topic_id
Dan kan je door middel van de koppel-tabel (read) kijken of hij er in staat.
Zo niet; niet gelezen
Zo wel; wel gelezen
Zelfs kan je nog dateTime er aan toevoegen waardoor je weet wanneer hij hem gelezen heeft, of uitbreiden met kijken op de laatste post, heeft hij die gezien?
@Milo S
Er is maar 1 goeie methode om je koppeltabel niet tot in de eeuwigheid te laten groeien en dat is de omgekeerde methode:
Read
- id <- mag weggelaten worden, is zinloos in koppeltabellen.
- usr_id
- topic_id
Dan kan je door middel van de koppel-tabel (read) kijken of hij er NIET in staat.
Zo niet; WEL gelezen
Zo wel; NIET gelezen
en deze delete je meteen zodra een lid het topic leest.
Het is slecht voor je performance en laat je tabel oneindig groeien om het te doen zoals je in 24/12/2010 09:27:31 beschrijft.
@John D dat ligt er toch heel erg aan hoeveel bezoekers consistent hun berichten lezen? Stel, ik neem een forum als PHPhulp als voorbeeld, met 50.000 leden. Ik denk dat 2% van alle geregistreerden de afgelopen maand actief is geweest. Zou Bas een PM sturen naar iedereen, dan leest maar 2% hem, 49.000 blijft dan bij jouw in de database staan. Neem je Milo's methode, dan komt er maar 1.000 regels in de database bij.
Met forum topics is het nog veel erger. Niemand leest alle forum topics. Bij iedere nieuwe post 50.000 regels toevoegen aan je database voor alle ongelezen status, lijkt mij niet bepaald goed voor je performance.
Edit: voor topics zou ik per gebruiker opslaan wanneer hij voor het laatst dat topic heeft geopend. Zijn er berichten aan dat topic toegevoegd nadat hij het heeft gelezen, dan zijn er nieuwe berichten. Op die manier heb je maar $aantal_gebruikers * $aantal_topics regels nodig in het ergste geval, niet $aantal_gebruikers * $aantal_posts. Ik zie dat Milo ook zoiets voorstelt, maar als je de datum opslaat kan je ook aangeven vanaf welke post de posts nieuw zijn.
@Jelmer: Goed punt inderdaad en dan wel pas een record toevoegen wanneer iemand een topic leest/gelezen heeft. Dit laat wel de koppeltabel steeds maar groeien....
Voor wat betreft je opmerking bij mijn methode: 49.000 blijft dan in de database staan is een schoningsmethode makkelijk: Na 1 maand verklaar je alles wat nog niet gelezen is als WEL gelezen en delete je een oude maand (instelbaar x maanden terug) geheel uit de koppel tabel. Je hoeft daarvoor geen datum in de koppeltabel op te nemen, die staat immers in de topic tabel. Met deze methode voorkom je oneindige groei in de koppeltabel.
John D, die opschoning kun je ook doen als je de records toevoegt als er gelezen is. Al ben ik standaard geen fan van opschonen, ik bewaar graag alles
Je hebt dan:
Topics gelezen
Topics niet gelezen
Topics ouder dan een maand
Al ben ik standaard geen fan van opschonen, ik bewaar graag alles
Zolang je niet te maken hebt met uit zijn voegen groeiende database en daarmee gepaard gaan performance problemen kan je natuurlijk best bewaren omdat je graag alles bewaart. Toch vind ik dat je bij je datamodellering al na moet denken over schonen van gegevens die toch nooit meer geraardpleegd worden en die niet vallen onder een of andere bewaarplicht zoals de belasting. Dus niet bewaren om het bewaren!
Daar heb je gelijk in, al wordt komt er wel een export van de data voordat die uit de database verwijderd wordt (heb al een paar keer gehad dat het heel handig bleek dat die export er nog was)
@TJVB tvb: archiveren voordat je schoont is uiteraard een goeie zaak, dat kan je off-site bewaren op een ander en/of goedkoper medium.
[edit]
Voor Ozzie: Ik neem aan dat je uit deze topic een goeie methode kan bouwen.
