Struktur for læste/ulæste tråde i et forum

"der er kommet nye indlæg siden de sidst tjekkede"
Det ville jeg bare gøre med et timestamp du gemmer når de 'tjekker' og så hente alle de nyere indlæg ud siden sidst.

"brugerne skal se hvilke topics de har læst"
Hold det så simpelt som muligt her, sådan en tabel kan godt komme til at gøre ondt hvis du har et velbesøgt forum. Jeg tror ikke der er anden vej udenom at have en stor tabel med:
user_id | thread_id

og så krydstjekke den når du henter indlæg ud, for at finde ud af hvad der ikke er læst.

Jeg ville nok sætte en compound PRIMARY KEY på begge felter, så læsehastigheden optimeres.
PRIMARY KEY (user_id, thread_id)

Præcis derfor jeg kommer med spørgsmålet - der kan godt komme nogle performance problemer, hvis jeg lægger en række ind hver gang de besøger forummet! Måske skulle jeg gøre det således, at hvis forum_id'et allerede eksisterede for den pågældende bruger, så opdaterer den blot timestamp'et?

Hvis du kun sætter et timestamp per forum, kan du ikke se hvilke præcis indlæg den enkelte brugere har læst. Det var også det jeg mente, da jeg kommenterede på "der er kommet nye indlæg siden de sidst tjekkede".

Men hvis du vil gøre det her: "brugerne skal se hvilke topics de har læst" er der inden vej udenom. Så må du gemme hver enkelte kombination af user_id og thread_id (indlæggets id). Og så tjekke hver gang de læser et indlæg, om det er lagt i databasen, eller læg det ind.

På den måde kan du så med et JOIN finde ud af hvilke indlæg der er læst ud fra en liste.

Det er en fin nok måde at gøre det på, så længe tabellen er lavet ordenligt. Den måde jeg beskrev ovenfor er samme måde som PHPBB gør det, og det fungerer fint der.

En tabel med et par millioner rækker er ikke noget problem for mysql, den kan sagtens indeholde flere 100 millioner række uden problemer (dog ikke på et billigt webhotel). Performance problemer kan dog opstå ved at skrive til den for tit (mange gange i sekundet), da indexet skal opdateres hver gang.

Pas på du ikke kommer ud i 'premate optimization', vent med at optimere til det er nødvendigt. Hvis du virkeligt får det problem, så tillykke med et succesfuldt site :)

Tak for det, intenz - man får stuvet ørerne fulde omkring det med performance omkring databasen. :)

Så lidt :)

De fleste performance problemer kan undgås ved at sætte sine indexes 'rigtigt' (de vigtigste ting i WHERE kald) og ikke bruge flere end nødvendigt. Og så altid joine på et index, helst PRIMARY KEY.

Og ellers minimere antallet af kald til databasen mest muligt fra f.eks. PHP. Så undgå at lave 3 kald når man kunne have lavet 1 med de rigtige joins.

Næste skridt er så caching, men der skal man have behovet inden det er det værd at implementere.

den første ting har jeg gjort - de næste to har jeg vel gjort 75% :) så kan det ikke gå helt galt :)