Die Markierung in die Topic-Tabelle zu legen wäre wohl keine so gute Idee.
Wenn du ein grosses Board hast werden zwar alle Markierungen wieder entfernt sobald ein neuer Beitrag geschrieben wird. Allerdings wird irgendwann der letzte Beitrag im Thema geschrieben und ab diesem Zeitpunkt bleiben die Markierungen erhalten, verbrauchen Speicherplatz und bremsen die Thementabelle aus.
Ich kenne mich nicht so genau mit den Speichermethoden von MySQL aus, könnte mir aber vorstellen das variable Felder, die sich so oft ändern wie die Markierungen, die Tabelle ganz ordentlich fragmentieren würden was sich, gerade bei einer hochfrequentierten Tabelle wie der Thementabelle, wohl ziemlich ungünstig auf die Geschwindigkeit auswirken würde. Man könnte die Tabelle zwar regelmäßig optimieren, aber das wäre wohl auch nicht Sinn der Sache.
Wenn du die Markierungen in der Session-Tabelle ablegst wäre das weniger tragisch da sich der Inhalt dieser Tabelle sowieso mehrmals am Tag komplett ändert.
Ich würde die Markierungen auch nicht über die Session hinaus halten. Das würde nur eine Menge Speicherplatz verbrauchen. Stell dir mal vor du hast 100 aktive Mitglieder und jedes liest 10 ungelesene Themen pro Tag. Dann hast du 1000 neue Markierungen jeden Tag die dauerhauft gespeichert werden. Angenommen eine Markierung verbraucht durchschnittlich 15 Zeichen (Themenid, Timestamp der Markierung, ein paar Trennzeichen) sammeln sich da mit der Zeit eine Menge Daten an die eigentlich nutzlos sind.

Deswegen meine Idee, dass ganze in einen Cookie auszulagern...

Ich denke da gibt es eine andere Möglichkeit, als die von dir genannte. ;)
Ungetestet und aus einem Geistesblitz heraus:
Nehmen wir an, dass das ganze in diesem Format gespeichert ist:
1,2,3,45,123,
Nehmen wir weiter an, dass der User die Userid "45" besitzt. Nun überprüfen wir wie folgt, ob der User das Thema bereits gelesen hat:
Peinlich ist mir grade nur, dass ich vergessen habe, wie der entsprechende PHP-Befehl dafür lautet... ^^"
Obiges Beispiel ist also als Mischung zwischen Java und PHP anzusehen... ^^"
Edit: Ich glaube der Befehl hieß in PHP strpos... oder? ^^"
Na ja... fü`r`s Beispiel ist das wohl nicht so extrem wichtig...

Da nur alte Themen (hier könnte wieder oben genannte Beschränkung in Kraft treten, obwohl mir die missfällt) nicht andauernd gelöscht werden (neues Posting = alle bisherigen Userid`s löschen) sollte allerdings das Problem mit der Datenbankgröße nicht so extrem sein.

Edit:
Ok. Da hast du natürlich auch wieder recht...

Wie gesagt... das ist mir (leider|zum Glück) klar...
Alternativ könnte man da tatsächlich ein Zeitlimit einfügen... schlimmer als das ganze in die Session-Tabelle zu schreiben wäre das auch nicht, obwohl es mir gegen den Strich geht... zur Verdeutlichung: Wenn letztes Posting länger her als X-Tage, dann lösche Tabelle und sage immer alt.

Wenn die Posting-Tabelle dabei nicht so stark belastet werden soll könnte man das ganze in eine extra Tabelle auslagern... wobei man sich das ganze dann auch wieder einfacher machen könnte...

Werden sie ja nicht. ^^"

Jede Markierung würde nach meinem Beispiel Länge_der_UserID+1 Zeichen (",") kosten.

int strpos ( string haystack, string needle [, int offset])

Aber die meisten Themen sind doch "alte" Themen. Diskutiert wird doch meist nur in den neusten 5 oder, in grossen Boards, auch in den neusten 10.

Die brauchst aber auch den Zeitpunkt der Markierung um, bei einem neuen Beitrag im Thema, feststellen zu können ob diese Markierung überhaupt noch gültig ist. Sonst macht jemand einen neuen Beitrag im Thema und es wird immer noch als gelesen angezeigt. Das gleiche gilt für die Gelesen-Markierung für Foren.

Nicht für einen User, der sich neu angemeldet hat. Da können durchaus nochmal interessante Aspekte in einer bis dahin tot geglaubten Diskussion auftauchen.

Nein. Ich überprüfe nur, ob der User seit dem neusten Beitrag das Topic betreten, bzw. gelesen hat. Wenn er es betreten hat, ist das Thema alt, ansonsten neu.
Wenn ein neuer Beitrag hinzugefügt wurde ist das Thema natürlich für alle User neu. Ergo hat das "neue Thema" noch kein User gelesen, also werden alle UserID`s, die bisher das Thema besucht haben gelöscht -> Datenbank leer.

Das ist dann aber eher der seltenere Fall.


Stimmt, wenn du die Markierungen in der Themen-Tabelle ablegst würde das so funktionieren. Das hat aber, wie ein paar Beiträge weiter oben schon angesprochen, einige Nachteile.
Ich persöhnlich favorisiere es die Markierungen in der Session-Tabelle abzulegen. Vorteil: der Speicherplatz für die Markierungen wird automatisch wieder freigegeben und die Datenbank kaum gebremst, das System ist nicht von Cookies, also vom Client, abhängig und kann somit von jedem Benutzer (auch von Gästen), unabhängig vom Browser, genutzt werden.
Markierungen anderweitig über die Session hinaus aufzubewahren finde ich persöhnlich nicht gut. Das erhöht nur das Speichervolumen, ist resourcenlastiger, und bringt dem Benutzer nicht unbedingt einen Mehrwert. Ich persöhnlich jedenfalls lese ein Thema, was ich bei einem Besuch nicht gelesen habe, bestimmt nicht beim nächsten ;)

Ich schon. Ich hab z.B. morgens, bevor ich mich auf den Weg zur Schule mache, ca. 10 Minuten Zeit. In dieser Zeit "sprinte" ich durch zig Foren und gucke, was es an interessanten Themen gibt, manche lese ich dann auch, zumindest teilweise.
Insofern ist es für mich persönlich immer ärgerlich, wenn ich deswegen andere, für mich neue, Themen übersehe, nur weil ich sie nicht beim ersten Besuch gelesen habe.

In dem Fall könnte man speziell dieses Feld in eine extra Tabelle eintragen. Möglicherweise sogar in eine Datei. Die Datenbank-Tabelle wäre dann wie folgt aufgebaut:
int topic_id; text userlist

Die Datei, die mir im so im Gedankengang sogar besser gefallen würde wie folgt:
Ein Array in serialisierter Form:
$array[$topicid] = $userlist;

Anstelle der serialisierten Variante könnte das ganze direkt in PHP sein, so dass die Datei nur noch included werden muss.
Bei zuviel Daten würde mich das aber auch nicht gefallen... :-/

Wenn du für jedes Thema eine extra Datei anlegst ist diese Variante nicht zu gebrauchen. Wenn du erstmal mehrere tausend Dateien in einem Ordner liegen hast werden die Festplattenzugriffe entsprechend langsam. Wenn du dann für eine Themenauflistung 15-20 Festplattenzugriffe brauchst, 15-20 Dateien einlesen und "entserialisieren" willst geht die Ausführungszeit des Scripts in den Keller.

Na gut. Du hast mich überzeugt... also erst das Session-System ausarbeiten und dann diese Spalte darein packen... ;)

Danke für deine Hilfe (und Gedult). :)

Edit: Huch... hab ich doch tatsächlich statt "überzeugt" "überredet" geschrieben... ^^"
Sorry. ^^"