Schon gelesen?

Jeder kennt das Prinzip im Forum....
Ob man schon den neusten Post in thread xy schon gelesen hat oder nicht
doch wie frage ich am besten ab
Per cookies? Wäre ja für Leute an verschiedenen PC's nicht so gut...
oder in der DB... naja bin nicht überzeugt von der Methode, wobei wohl das die beste Lösung wäre
Nunja meine Frage
Wie speichert man am Besten die Infos in der DB ab damit es nicht zu komplex wird und wie
Meine Idee wäre für jeden thread ne spalte zu machen indem die leute reinkommen die schon den Thread besucht haben... Sollte nun ein neuer Post dazu kommen, wird nun diese Spalte gelöscht...

Wie meinst du für jeden Threat ne Spalte? Hab ich nicht ganz verstanden.
Viele Foren merken sich den letzten Besuch und heben dann die hervor, die nach dem letzten Besuch angelegt wurden.

Ich hab eine eigene Tabelle dafür:
user_id | thread_id
Und dann speicher ich dort alle Threads rein, wo seit dem letzten Besuch des Users etwas dazugekommen ist.

Original von progs
Ich hab eine eigene Tabelle dafür:
user_id | thread_id
Und dann speicher ich dort alle Threads rein, wo seit dem letzten Besuch des Users etwas dazugekommen ist.

naja aber dann musst du das doch für jeden user einzeln reinsetzen eine datenbank
jetzt stell dir dasmal bei 100000 User vor die mal 3 std nciht da sind
nun werden in dieser zeit in 50 threads was reingeschrieben und schon hat man 5 millionen neue datensätze
oder hab ich was an deiner methode missverstanden?

Original von Kampfhoernchen
Wie meinst du für jeden Threat ne Spalte? Hab ich nicht ganz verstanden.
Viele Foren merken sich den letzten Besuch und heben dann die hervor, die nach dem letzten Besuch angelegt wurden.

genau aber wie macht man das am besten
habs mir jetzt so gedacht
in der tabelle wo die threads sind ne extra spalte: VisitorsSinceLastUpdate
so wenn jemand jetzt diesen thread öffnet wird seine id da reingetragen im stil von USER1;USER2;USER3
sollte man nun in dieser liste nicht drinnstehen hat man den thread noch nicht besucht seitdem es den neusten post gibt......
und sobald jemand in diesem thread einen neuen post schreibt wird
VisitorsSinceLastUpdate auf "" gesetzt

Weißt du wie lange du da drin suchst wenn man 1000 User hat?
Volltextsuche ist nicht grade besonders performant.
Meine ist die schnelle Lösung, die von progs die gute. Auch wenn sich bei seiner natürlich wieder massig Datensätze ansammeln. Insbesondere natürlich problematisch bei inaktiven.

gibts denn nen benchmark wie lange das bei ca. 1000 oder 10000 usern dauert?
sind ja eigentlich so ca 70000 zeichen die er da nur durchsuchen muss
oder soltle man das durchsuchen evtl durch j-script machen das der server nciht überlastet wird?
ich denke meine wäre auch die gute lösung allerdings inperformant^^

Original von esport-com
oder soltle man das durchsuchen evtl durch j-script machen das der server nciht überlastet wird?
ich denke meine wäre auch die gute lösung allerdings inperformant^^

Also das würde ich auf jedem Fall auf dem Server machen. Da gibt es viele Argumente für: Datenschutz, Kompatibilität, etc. Außerdem bezweifel ich, dass der Server dann viel weniger Arbeit hat, da er ja die ganzen Daten an den Client schicken müsste.
Ich denke, dass eine Lösung wie die von Kampfhoernchen das effektiveste ist. MySQL soll ja sehr gut auch mit sehr großen Datenmengen umgehen können.
Ich würde das wohl so machen: Wenn ein User einen Thread ließt, wird folgende Tabelle upgedatet oder eine Zeile erstellt:
userID | threadID | timestamp
Die Abfrage nach neuen Threads lautet dann (pseudo):
table = SELECT * FROM table WHERE userID=$userid AND threadID=$threadid
read = false;
if(thread.lastPostStamp < table.timestamp){
read = true;
}

Original von Kampfhoernchen
Weißt du wie lange du da drin suchst wenn man 1000 User hat?
Volltextsuche ist nicht grade besonders performant.
Meine ist die schnelle Lösung, die von progs die gute. Auch wenn sich bei seiner natürlich wieder massig Datensätze ansammeln. Insbesondere natürlich problematisch bei inaktiven.

Am Besten ist meiner Meinung nach die Kombination von beidem. Wenn der User wieder on kommt dann kommt das Update, welches in die Tabelle von progs alles reinschreibt. Vielleicht noch ne Spalte mitn timestamp, so dass man neue beiträge, die die user nicht gelesen haben, nach einer gewissen Zeit wieder löscht.
edit: hab mal sogil mit progs getauscht. Ich weiß nicht wie ich auf sogil kommt -.-

am besten für jeden user speichern welche threads er wann zuletzt angeschaut hat
user_id,thread_id,lastvisit
wenn es keinen eintrag gibt ist der thread komplett neu, sonst nur wenn der letzte post in dem thread > last_visit
ist auch performant, da nicht jeder user alle threads sich anschaut, so das die maxanzahl von user*threads nie erreicht wird. ausserdem sit die table static und mit sinnvollen keys ist das auch fix

Original von KoMtuR

Original von Kampfhoernchen
Weißt du wie lange du da drin suchst wenn man 1000 User hat?
Volltextsuche ist nicht grade besonders performant.
Meine ist die schnelle Lösung, die von progs die gute. Auch wenn sich bei seiner natürlich wieder massig Datensätze ansammeln. Insbesondere natürlich problematisch bei inaktiven.

Am Besten ist meiner Meinung nach die Kombination von beidem. Wenn der User wieder on kommt dann kommt das Update, welches in die Tabelle von sogil alles reinschreibt. Vielleicht noch ne Spalte mitn timestamp, so dass man neue beiträge, die die user nicht gelesen haben, nach einer gewissen Zeit wieder löscht.
Genauso ist es bei mir. Speichere dazu noch den Timestamp, wann da ganze in die DB gelegt wurde. Der Eintrag in die Tabelle erfolgt erst, wenn der User wieder online kommt. Und EInträge, welche mehrere STunden nicht angeschaut wurden, werden dann beim nächsten Besuch aus der Tabelle gelöscht.

Original von progs
Genauso ist es bei mir. Speichere dazu noch den Timestamp, wann da ganze in die DB gelegt wurde. Der Eintrag in die Tabelle erfolgt erst, wenn der User wieder online kommt. Und EInträge, welche mehrere STunden nicht angeschaut wurden, werden dann beim nächsten Besuch aus der Tabelle gelöscht.

Ok das stand im ersten Posting nicht drin. Dachte erst du speicherst beim anlegen einenes neuen Threads auch gleich was in die Tabelle rein. Ich denke deswegen kamen auch solche Antworten

Original von KoMtuR
Ok das stand im ersten Posting nicht drin. Dachte erst du speicherst beim anlegen einenes neuen Threads auch gleich was in die Tabelle rein. Ich denke deswegen kamen auch solche Antworten

Nein, hatte ich nicht für nötig gehalten hinzuschreiben. Wäre etwas aufwendig, dies für alle User bei erstellen zu in die DB zu speichern.

Original von esport-com
naja aber dann musst du das doch für jeden user einzeln reinsetzen eine datenbank
jetzt stell dir dasmal bei 100000 User vor die mal 3 std nciht da sind
nun werden in dieser zeit in 50 threads was reingeschrieben und schon hat man 5 millionen neue datensätze

Dabei sind die Datenmengen nicht einmal das Problem. Aber wenn ich einen neuen Beitrag zu einer Diskusion schreibe, bedeutet das, dass ich 100.000 Datensätze in die Datenbank schreiben müste.
Ich habe das Problem gelöst, in dem ich das Forum ähnlich wie subversion versioniere. Für jeden Benutzer wird dann gespeichert, welche neusten Versionen er auf den verschiedenen Ebenen kennt. Man kommt so mit relativ wenig Daten pro Benutzer aus und hat nur Updates auf diese Daten, wenn ein Benutzer einen Beitrag liest, aber nicht, wenn irgend welche Beiträge geschrieben werden.

Meine Version ist kompliziert, aber einfach ():
Wenn ein Spieler alle Themen gelesen hat, wird ein timestamp in der Usertabelle aktualisiert.
Dieser Timestamp ist standardmässig auf das Registrierungsdatum gestellt.
Wenn der Spieler nun ein Thema liest, wird ein Eintrag in einer eigenen Tabelle gemacht, wann er das gelesen hat.
Daraufhin kann ich alle Themen, die "neuer" (bei jedem Post/edit drin wird der timestamp vom thread aktualisiert) sind, anzeigen - basierend darauf, dass der timestamp vom Thema neuer ist als der Spieler-Timestamp UND neuer als der Spieler-hat-Thema-Gelesen-Timestamp. Wenn diese Zahl 0 wird (alle Themen wieder mal durchgelesen), kann ich alle Einträge in der Tabelle löschen und den Spieler-Timestamp aktualisieren.
Ebenso kann ich ab einem gewissen alter Einträge in der Tabelle löschen und den Spieler-Timestamp dafür aktualisieren - Beiträge, die älter als ein Monat sind, müssen nicht mehr gelesen werden imho.
Vom Speicherplatz und der Perfomance ist das meiner Meinung nach perfekt, was auch nötig ist, da das Forum direkt integriert ist und man im Spiel gleich weiß wann was neues ist (wens interessiert: aquarion.org/ , Gastaccount anklicken).
Weitere Gedankengänge dazu:
Bei uns gibts (natürlich, wie überall) verschiedene Typen von Forenlesern. Die einen, auch oft Spammer, lesen aus Prinzip alles durch was neu ist (wird auch durch die Überwachung im Kopfmenu stark gefördert.). Daher haben die meist nur wenige Einträge in der Tabelle, und oft nur einen Timestamp in ihrer Tabelle.
Die anderen lesen sich vielleicht 1-30 Themen durch, oder nur die eigenen, was für wenig Datenmüll sorgt - und irgendwann kann man den sowieso wegräumen.
Die schlechteste Variante wäre die von esport: "USER1;USER2;USER3" ist zwar vom Speicherplatz her nett, von der Perfomance der Durchsuchbarkeit extrem furchtbar und von der Wartbarkeit etc. ebenso ein Grauen.
Nichts gegen dich, ich will dich nur davon abhalten einen gravierenden Fehler zu begehen

von der verwertbarkeit her wäre es kein problem

if(preg($user,$string))
{
//Bereits gelesen
}
else
{
//noch nicht gelesen
}
das es performant furchtbar ist, ist mir bekannt
deswegen hab ich ja gefragt

Die verwertbarkeit, die du es schön zitierst, wäre ein Verbrechen an deinen Server.
Du müsstest *jedes* Thema extra abrufen, für *jeden* Spieler, und dann für jeden dieser Strings die du da bekommst, diese Regular Expression drüber laufen lassen.
Abgesehen vom gewaltigen Overhead, der da irgendwann zusammenkommt, kannst du keine Simple Abfragen machen wie z.B. Welches hat er am längsten nicht gelesen, etc...

Mal davon abgesehen, dass er jedesmal pro Thema einen rießen String aus der DB lesen muss und an PHP geben. Wenn der DB-Server dann auch irgendwann mal ein eigener Server ist, entsteht da eine rießen Netzwerklast.