Gelesen-Funktion - wie funktioniert das?

da gibt es verschiedene varianten.

eine davon ist zu speichern wann ein benutzer das letzte mal online war. diese zeit wird mit der zeit verglichen wann in einem thema der letzte beitrag geschrieben wurde.

dadurch "weiß" das forum ob das thema für einen benutzer neu ist oder nicht.

wenn ein benutzer ein neues thema jetzt gelesen wird das beispielsweise in der datenbank, in cookies oder in einer session variable gespeichert.

möglichkeiten gibt es viele

Danke erstmal. Das mit den neuen Themen habe ich mir schon so vorgestellt, aber..
...speziell dieser Teil ist mir unklar.

Früher beim YaBB war dies so:
Dort wurde separat gespeichert, wann du das letzte mal in einem Forum oder Thema warst und dann wurde verglichen.

Problem an der Sache: Je mehr User und Beiträge, Themen und Foren es gibt, desto größer wird die Anzahl der Datensätze die es zu verwalten gilt. Auf Dauer geht sowas auf die Performance.

Nehmen wir mal ein Board mit 100 Benutzern, 1000 Themen und 20 Foren an. Dort kann es sein das das Board 120000 Datensätze zu verwalten hat. Und das bei einem kleinen Board. gehen wir mal von meinem aus, so muss das System im schlimmsten Fall über 24 Millionen Datensätze verwalten.

Und die sollen mal auf dauer performant nach den passenden Datensatz durchsucht werden. Das geht nicht, erst recht nicht wenn über 100 User online sind (wie es bei so mancehhn Board äusserst üblich ist). beim YaBB kam es so schonmal zum Datenverlust.

Deswegen hat sich diese Methode wohl nicht durchgesetzt, obwohl sie für den user wohl die komfortabelste Möglichkeit ist.

Eine andere Möglichkeit die heut sehr verbreitet ist: Man vergleicht die Zeit wann ein User das letzte mal online war mit der Zeit des letzten Beitrags. Um das ganze dann noch ein wenig benutzerfreundlicher zu machen, werden noch zusätzlich Zeitwerte in der Session und im Cookie gespeichert, mit diesen kann man dann sehen ob der User in der Zeit in der er online war sich schon ein Thema angesehen hat und man kann darauf reagieren (anderes Icon etc.).

Das ist die Methode die oben beschrieben wird.

auf phpBB2.de wurde mal ein Hack eingebaut, welcher angeblich diese Funktion verbesserte. Ergebnis sind auf jeder Seite bis zu 120 Queries und steigend.

120 Querys?
Das kann ja nur von phpBB2.de kommen

Keine Sorge, die schaffen auch locker das Doppelte

Ich hab da jetzt mal drüber geschlafen (nicht besonders lange, leider): ich denke die beste Lösung wäre eine Tabelle, in der die "gelesen" Markierungen temporär gespeichert werden, und zwar so lange, wie Beiträge generell als "neu" gelten. Es muss doch irgendwie möglich sein, mit max. 2 od. 3 zusätzlichen Queries auszukommen...?

120 Queries? Kann man sich das wo anschauen?

Jetzt war ich kurz auf phpbb2.de
Wie kann man nur 412 Queries verpfeffern?
Edit: Ich bin immer noch ganz erschüttert

Scheinbar hat dort jede Seite über 100 Querys. Nicht grad ein gutes Vorbild wenn sich jemand für das phpbb2 interessiert.

je nachdem wie du deine tabelle aufbaust würde es sogar reichen wenn es nur ein Query wäre.

Beispiel Tabelle:
userid
threadid
lastreaddate

alles drei INT Spalten.

Nun brauchst du nur noch die ThemenIDs und schon kannst du mit einem Query in der Art die Zeit Werte abrufen.

SELECT * FROM tabelle WHERE threadid IN (1,2,3,4,5) && userid=1

Die Zahlenwerte musst du natürlich entsprechend austauschen.

phpbb2.de hat ja so viele queries weil die alle möglichen Mods einbauen, anstatt diese entsprechend zu kombinieren.

Und ich möchte auch einmal an dieser Stelle darauf hinweisen, daß es einen herheblichen Unterschied ausmacht, ob man 5 Queries hat, die je 0.002 Sekunden dauern, oder eine Query die satte 7 Sekunden dauert.

Posting pages haben normalerweise mehr Queries (durch die UPDATES/INSERTS), dafür sind die aber schön schnell.

Die Anzahl der Queries ist deshalb kein Garant dafür, wie schnell ein Board nun tatsächlich ist.

Dies ist schon korrekt, jedoch erhöht sich mit jedem zusätzlichen Query die Gefahr das einer hängen bleibt und die besagten 7 Sekunden brauch.

Im übrigen schauen sich die meisten Nutzer die Query Zahl sehr genau an, da sie dort zu sehen glauben ob ein Datenbankserver stark belastet wird und wie gut ein System geschrieben ist. Denn es ist schon sehr eigenartig wenn zwischen zwei Systemen die das gleiche vollbringen ein Unterschied von 15 und mehr Querys liegt.

Und auch wenn ein Query nur 0.002 Sekunden brauch sind es bei 100 Querys doch schon 0.200 Sekunden. Zwar kein Beinbruch aber es geht halt schneller.

hm... also wenn du ne simple lösung willst

erstelle eine tabelle mit userid postid... es wird NUR DANN etwas hineingeschrieben wenn der user das post auch gelesen hat. Logischerweise sind alle post ids die nicht gefunden werden oder keine userid als gegenpart haben nicht gelesen / nicht von dem user gelesen.. wenn du das noch zusammen mit ner zeitangabe verbindest (meinetwegen alle posts die net älter sind als x tage) hättest du deine lösung... ich glaub super performant wäre die aber nicht

Klar, da hast du natürlich Recht, ich meinte es ja auch in kleinem Rahmen. Wer unten 100 Queries stehen hat, der macht wirklich was falsch.

Ich glaube, das wäre sogar ziemlich performant, wenn man es gescheit schreibt
412 Queries sind aber - egal, wie stark die den Server belasten -eindeutig zuviel. Ist meine Meinung.

Hi @ll

die Performateste Lösung ist sicher.
die Foren als ungelsen zu makieren, die sich nach dem letzten betritt verändert haben.

Ist schnell zum rausfinden.
verliert sich nur sehr schnell.

Eine möglichkeit wäre es eine mischform aus dem ganzen zu bauen.
das man ein Cookie mitschleift, was er sich in der session alles angeschaut hat.
Sobald er die Seite verlässt, wird das Cookie verworfen.
In dem Cookie, werden die ID's der Thread's angeführt welcher er sich angeschaut hat.
Zusätzlich, könnte man bei der Funktion, "diese Sektion als gelesen makieren", dies genauso in dem Cookie mit führen.
so würden alle IDs von dieser Sektion rausfliegen.
So schafft man wieder Platz im Cookie.

Das ganze in die DB zu speichern, ist der falsche Weg, wie schon einige Vorschreiber beschrieben haben.
So kommen zuviele Query's bzw. Datensätze zusammen.

Die Methode die ich beschrieben habe, ist mir gerade eingefallen, wobei mir die Idee recht gut gefällt.

Hat GeschwindigkeitsVorteile.
Falls der User kein Cookie zulässt, kann man es noch in der Session einbaun, was ich aber ned für sinnvoll erachte.

@Daddycool
Schön dich hier zu finden.
du alter "Code Quäler" (derzeitiger Status).

@Nev
schön dich zu lesen

In meinem aktuellen Board Entwurf funktioniert dies so:

Kommt ein Nutzer online so lese ich den Zeitwert seines letzten besuches entweder aus der Benutzertabelle oder aus einer speziellen Gasttabelle (sofern er als widerkehrender gast identifiziert wurde) aus

Dieser Wert wird in der Session gespeichert, damit dieser auch bei einem Seitenwechsel erhalten bleibt.

Alle Gelesen/Ungelesen Icons richten sich nun nach diesem Wert. Zusätzlich speicher ich noch zusätzliche Werte in der Session. Betritt ein Benutzer z.B. ein Forum so wird dieses mit einem Zeitwert in die Session gespeichert und das Forum als gelesen markiert. Das gleiche bei Themen.

Hi @gain

das System hat vorteile, da es sehr schlank wirkt.

Aber die Funktionalität die gewünscht wird, erreicht es ned.

um das zu machen, kann man wie von anderen beschrieben, das ganze in der DB spielen, was ned gerade das schlauste ist (wenn man mal hochrechnet).

Die andere Möglichkeit wäre es, nicht gesamt die Funktionalität wiederzuspeigeln, sondern es so gut wie möglich umzusetzten, daher meine Idee.

Das mit dem Cookie kann man recht nett umsetzten.
Man speichert, serializert die thread-ID`s mit den ForenID's ab.
sicher kommst an die Cookie Grenze, aber das kann man noch umgehn, irgendwie.
Falls er ein Forum als gelesen makiert, wird das im Cookie vermerkt und die dazugehörigen Thread-ID`s gelöscht.

Muss man mal austesten, wie gut das gehn würde.
War wie gesagt gerade ein Gedankengang.

Hi ciruZ

ob du es jetzt im Cookie, oder in der Session miführst, ist eigendlich egal.

Da ich ein eigenes Verhältnis zur Session-Verwaltung von PHP habe, nehme ich die Cookies.

Wobei das auch nur Session-Cookies sind.

Warum denn alles ins Cookie schreiben??

Gib den Gast doch eine eindeutige ID und speicher das ganze in eine spezielle Tabelle, so wie ich es mache (meine ominöse Gasttabelle).

Jeder Gast bekommt eine eindeutige ID, zu dieser ID gibt es (normalerweise) einen Datensatz in der DB. Dort werden verschiedene daten zwischengespeichert (Dinge die sonst möglichweise in ein Cookie kommen würden). Kommt ein Gast nun wieder und hat nochs eine ID so wird der Datensatz ausgelesen und in die Session übernommen.

Natürlich werden in dieser Tabelle keine Passwörter für Foren usw. gespeichert.

Das ganze lässt sich dann auch noch auf einen registrierten user anwenden. Dort legt man halt ein extra Feld an wo die Daten reinkommen.

Für solche Fälle wird noch ein Zeitwert gespeichert, über diesen kann der Admin dann alte Einträge killen.

Hab also mitgedacht

@DaddyCool

Sicher kannst du es über einen Table lösen, mach ich ned anderes.

Um das ganze noch schneller zu machen, lagere ich einiges ins Cookie aus.
Falls der User keines zulässt, rennt das "Cookie" in der DB.

@ciruZ
Was DaddyCool meint ist, das er User bzw. Gast nur für die eine Session gleich bleibt, danach wird die Row wieder gelöscht, bzw. wertlos.

Es soll tatsächlich Leute geben die nur Lesen wollen, um sich zu informieren, und da in Themenforen öfter Dinge hinzukommen ist es dort sehr wahrscheinlich das ein Benutzer mehrmals aufkreuzt.

In meinem kleinen Board sind ziemlich viele Gäste unterwegs, und ich kann mir ehrlich gesagt nicht vorstellen das ALLE zum ersten mal da sind. Ein Teil davon gehört sicherlich zu den Stammgästen.

Edit: Ein Stammgast ist mir übrigends lieber als ein nullposter, wobei der Nullposter besser für die Statistik ist.

@ciruZ

Nee eben ned.
Wenn der Browser zu ist, dann ist die Session weg.
ist auch sinn der sache.


das andere Boards die Session weiterbehalten, ist mir bekannt, nur ist das sinnvoll??

PS: gefällt mir hier recht gut.
Überhaupt das ich aus den 2 Themen wo ich derzeit gepostet habe, ned rauskomm, da immer irgendwer was das dazuschreibt ;-)

@Nev
Um nicht irgendwann im Datenchaos zu enden ahbe ich irgendwann beschlossen das für alle die gleichen Regeln gelten, d.h. alle nutzen die gleichen Methoden zum Speichern von Werten oder schauen in die Röhre.

Sonst habe ich irgendwann 10 arrays mit Werten die jeweils an anderen Stellen gespeichert wurden. bei sowas wird es dann schwer zu bestimmen welches Array was für eine gewichtung bekommt.

Aus diesem Grund werden bei mir genau vier Werte in die Cookies geschrieben.

Session ID
Guest ID
User ID (falls registriert)
Passwort (verschlüsselt, falls registriert)

Die längsten Werte sind 32 Bytes lang, und soviel Platz sollte ein user schon haben , um mal wieder auf das problem mit dem platz in den cookies zurückzukommen