Gelesen-Funktion - wie funktioniert das?
 

In anderen Threads habe ich rausgehört, dass verschiedenste Wege beschritten werden, eine Gelesen/Ungelesen Funktion in Forensoftware zu implementieren.
Wie funktioniert so eine Funktion überhaupt? Werden alle Threads, die ein User gelesen hat, in eine separate Tabelle geschrieben? Läuft das mit Cookies?
Wäre nett, wenn mir das wer erklären könnte :)

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 :D

Keine Sorge, die schaffen auch locker das Doppelte :rolleyes:

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? :eek:

Jetzt war ich kurz auf phpbb2.de
Wie kann man nur 412 Queries verpfeffern? :eek:
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 :D

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 :D

@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

Hi ciruZ

Das "normale" Session-Timeout liegt bei 30 min.
was du meinst, ist:
wenn der User den Browser zumacht, und sofort bzw. in einen bestimmten Zeitraum die seite betritt, das er die selbe SessionID bekommt.

das ist Möglich, da wenn du das normale Session-Handlinfg von PHP verwendest, die Session nicht abläuft, sobald man den Browser zumacht.
Ist ein großer grober Fehler.
Warum das passiert ist auch logisch.
da viele Systeme die SessionId im Table speichern und zusätzlich ein Cookie absetzten.

So bekommt er falls die Session noch ned abgelaufen ist die selbe.

@DaddyCool
Sicher sollte man das Cookie klein halten, bzw gar ned verwenden.
Bin nicht gerade der Freund von Cookies, aber manchmal können diese schon sehr nützlich sein.
Wenn man Cookies verwendet, soll man auch wissen warum, bzw. welche Nachteile sie bringen können.

Was ich bei meinem Kommentar im anderen Thread "RechteSystem" vergessen habe, ist das ich auch einen GastID habe.
aber das werde ich drüben noch nachziehn

Der größte Nachteil dürfte wohl sein das der User solche Daten manipulieren kann (was bei verschiedenen Systemen schon zu unschönen Sicherheitslöcher geführt hat).

Aus diesem Grund limitiere ich soetwas aufs nötigste und speicher nur dort Werte die sich wirklich nirgends anders unterbringen lassen.

Nun könnte man natürlich den Einwand bringen das meine Guest ID Methode auch nicht das wahre ist, da man soetwas übernehmen kann. Dies ist auch korrekt, jedoch können keine Werte verändert werden und in der Tabelle werden nur ungefährliche Daten gespeichert.

Hi @gain

Du musst auch unterscheiden, welche Cookie-art du verwendest.

Wenn du ein permanetes Cookie hast, kannst du daten sehr leicht manipulieren.

bei einem Session-Cookie wird es schon sehr schwer.

Gebe dir aber recht, das man so wenig Daten wie möglich dort reinspeichern sollte.

Werde das wahrscheinlich auch in meinen neuen System umändern, so das hier nix mehr bzw ganz wenig drinsteht.

Falls was drin steht, mit denen er nichts anfangen kann.

Eine andere Lösung wäre es das Cookie zu verschlüsseln.

Dann müsste es aber eine Methode sei die sich rückgängig machen lässt und wo z.B. der Admin den "salt" (siehe crypt()) bestimmen kann. Ansonsten wäre die methode bereits nachdem Release der Software für den Ar...

Hat mal jemand nen Link zu Verschlüsselungsmethoden parat wo auch beschrieben wird wie diese arbeiten, so das man dieses umsetzen könnte?? (ich will keinen Verweis auf mcrypt ;))

Ich bin auch gerade am überlegen, ob ein unregistrierter Gast den "Komfort" einer gelesen/ungelesen-Funktion nutzen soll/darf.

Ist ein Gast nicht immer unregistriert bzw. nicht angemeldet?? ;)

Wenn du das System für die Nutzer ohne Probleme auch auf die Gäste anwenden kannst (kann man z.B. bei dem System welches ich einsetze) dann solltest du es auch nutzen. Nutzt du ein System wie das YaBB nutzt(e). So ist dies nur mit einem sekundären System möglich. Dann solltest du ggf. darauf verzichten.

Wenn eins drin ist erhöht es aber den komfort.

Jaja, unregistrierter Gast :)
Ich meine nur, man sollte den Gästen einen (zusätzlichen) Anreiz geben, sich zu registrieren.

Sollten nicht die Diskussionen der Grund sein warum sich ein Nutzer registriert??

Kommt dann wieder darauf an, ob man Gästen das posten erlaubt.

Sorry dann, habe ich das falsch rausgelesen.

Was wolltest du nun wissen? Kenn mi ned mehr aus.

hat sicher vorteile, die ich derzeit aber nicht sehe, wenn ich das jetzt "richtig" verstanden habe.

Wenn er vor dem "Session"-Timeout die Seite wiederbetritt, bekommt er die alte "Session"??

Hi.
Ich habe mir auch mal Gedanken über dieses Thema gemacht. Nun wollte ich euch mal Fragen, was ihr davon haltet.
Das ganze basiert auf Cookies. In dem Cookie werden alle besuchten Topics in einem serializiertem Array der Form $array[$threadid] = $visittime; gespeichert.
Dann wird noch ein zweites Array für die besuchten Foren angelegt.
Auf diese Weise können auch Gäste vom Gelesensystem profitieren und das ganze geht nicht auf die Datenbank, ist dabei aber extrem genau.

Der größte Nachteil, den ich dabei sehe ist folgender: Bei einem sehr großen Board könnte es passieren, dass der Cookie zu groß wird. Was mache ich dann?
User, die keine Cookies zulassen können meine Software momentan gar nicht nutzen (nicht das es da viel zu nutzen gäbe...), von daher ist die Auslagerung dieser Funktion in Cookies kein Beinbruch für solche User. ^^"

Was ich mir noch vorstellen könnte, wäre eine Begrenzung der Topics, die überhaupt als neu gelten drüfen. Also z.B. Topics, die älter als 2 Tage sind, sind immer alt.
Wäre das eine brauchbare Lösung?

(Das die Zeit des letzten Besuchs mit der Zeit des neusten Postings verglichen wird sollte klar sein, oder? ^^")

Soviel ich mich erinnern kann, dürfen Cookies nur eine bestimmte Größe haben (2 kb?). Da müsstest du haargenau aufpassen, was du in den Cookie schreibst und was nicht.
Das schwebt mir auch vor --> brauchbare Idee ;)

Meines Wissens darf ein Cookie maximal 4kb haben. Das sollte aber auch reichen um für die Dauer einer Session die IDs der besuchten Themen festzuhalten.
Wobei ich das eher auf die Datenbank des Forums auslagern würde, da das ganze dann unabhängig vom Client ist. Du könntest beispielsweise in der Session-Tabelle eine Textspalte machen in der für jede Session die serialisierten Arrays abgelegt werden.
Die Anzahl der Topics, welche als neu gelten, zu begrenzen bringt dir auch nicht viel. Bei einem grossen Board gibt es auch innerhalb von 2 Tagen eine Menge neuer Themen die die Markierungen recht umfangreich werden lassen können. Mal davon abgesehen wäre das eine ziemlich unschöne Lösung.

Ausgehen von deinem (@exe) Text käme mir da noch folgende Idee, die aber wohl noch ausgebaut werden müsste...
Man könnte statt der Session-Tabelle (die ich in diesem frühen Stadium noch gar nicht habe..., bzw. nicht mit diesem Aufgabenbereich) auch ein solches Feld vom Typ text in der Topic-Tabelle einbinden.
Dort würden dann die Userid`s gespeichert, die das Thema bereits gelesen haben. Wird nun ein Eintrag zum Thema hinzugefügt wird dieses Feld geleert.
Das ist simpel umzusetzen, sollte die Performance kaum belasten, und dürfte für die Datenbank auch nicht belastender sein, als ein Posting.
Nachteil, den ich dabei sehe ist, dass die Gäste nicht mehr das Gelesensystem benutzen können...
Oder man schreibt das Array in die Usertabelle, und nicht in ein Cookie... aber dabei würde der Speicher nicht geleert werden...

Dagegen habe ich eigentlich nur folgendes einzuwenden. Wenn ich nun nur die Einträge der aktuellen Session speichere wären automatisch alle Beiträge, die in der vorigen Session nicht gelesen wurden alt, was aber nicht der Fall ist.
Deswegen kommt dieses System für mich nicht in Frage. Jedenfalls sehe ich in dem Bereich keine Möglichkeit, wie ich ein genaues System erreichen könnte.

Danke schonmal für eure Meinungen / Vorschläge.

Bau das mal in ein Forum mit zigtausend Benutzern ein - das gibt eins schön große Datenbank! Und wie ließt du aus, ob DIESER user das Thema schon gelesen hat?

$text = $db->getfield('text');
explode(...)
in_array()

?

ars ... lahm.