nieuw bericht
- 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.
Gewijzigd op 20/12/2010 20:25:13 door Aad B
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?
Succes!
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.
Gewijzigd op 24/12/2010 09:42:45 door John D
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.
Gewijzigd op 24/12/2010 09:49:03 door Jelmer -
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.
Je hebt dan:
Topics gelezen
Topics niet gelezen
Topics ouder dan een maand
TJVB tvb op 24/12/2010 10:03:01:
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!Al ben ik standaard geen fan van opschonen, ik bewaar graag alles
Edit:
Voor Ozzie: Ik neem aan dat je uit deze topic een goeie methode kan bouwen.
Voor Ozzie: Ik neem aan dat je uit deze topic een goeie methode kan bouwen.
Gewijzigd op 24/12/2010 10:24:04 door John D