Wolf66

Hallo.

Mich würde mal interessieren, wie ein gutes Forensystem funktioniert.

-Speicherung der Beiträge in Baumstruktur, und nicht als "Faden". Ähnlich wie bei Newsgroups.


Wie funktioniert sowas? Wird in jedem Beitrag dann eine "Parent-ID" und eine "Thread ID" eingetragen und der Aufbau erfolgt von "Unten nach oben"?

Signaturen und Username etc: Werden diese Sachen beim Erstellen in die Message kopiert oder werden diese Sachen beim Anzeigen per DB Query erst eingefügt?

Mister Ad

Asipak

Um eine Baumstruktur zu realisieren, bräuchte man schon so etwas wie eine Parent-ID. Was meinst du mit „von unten nach oben“? Eine Sortierung kann man nach unterschiedlichen Kritierien durchführen, beispielsweise nach dem Datum. Oder man erstellt eine separate Spalte in der Datenbank, die ausschließlich für die Sortierung zuständig ist.
Das kann man sich selbst beantworten, indem man sich fragt, was passiert, wenn der User seine Signatur ändert.

zwutz

kann man machen, wie man will.

wenn man die thread-id mitzieht hat man den Vorteil, dass man mit einer abfrage alle relevanten Beiträge hat. Die parent-id ist dann nur noch für die Darstellung relevant.

Sig und Username werden in der Regel erst am Ende eingefügt. So spart man sich den Platz in der DB und der User hat auch in alten Beiträgen seine aktuelle Sig. Der Benutzername sollte allein schon aus rechtlichen Gründen erst am Ende reinkommen, falls jemand seinen Namen löschen oder ändern lassen will

nikosch

[MOD: verschoben]

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Wolf66

Ja, die "Thead-ID" braucht man, um alle Beiträge eines Threads zu finden, Anders wirds wohl relativ kompliziert.
Parent Id brächte man, um halt die typische Vorfahr-Nachfahr Struktur auf einfache Weise zu machen.
So stelle ich mir das jedenfalls vor.

Bei Username und Signatur:
Ich kenne Foren, da wirken sich Änderungen nur auf neue Beiträge aus. Ich kenne auch Foren, wo es sich auch auf alte Beiträge auswirkt.

Wenn man die Sachen erst zur Laufzeit per Query einfügt, hat man natürlich viele, viele Querys mehr, als wenn z.B. die Signatur jedes mal bei der Beitragserstelung fest einkopiert wird.
Dafür hat man mehr Speicherplatzverbrauch.

chorn

---

Dark Guardian

Nested Sets wären eine Alternative zur üblichen Baumstruktur mit ParentId und Rekursion. Die ThreadId brauchst du nicht. Ein Thread ist eigentlich nur ein Post mit ParentId 0. Alles was einen Thread sonst noch besonders amcht, wie z.B. letzter Beitrag o.Ä. lässt sich aus allen anderen Daten live ermitteln.

Um die Performance dadurch nicht zu sehr zu drücken sind entsprechende Caching Verfahren angebracht. Wie beispielsweiße das Zwischenspeichern des letzten Beitragsdatums um nur dafür nicht immer die Beitragshierarchie ablaufen zu müssen.

Dennoch kann das Speichern der ThreadId zum Post sinnvoll sein. Denn du sparst dir dann das Suchen innerhalb der Hierarchie und kann direkt auf bestimmte Posts zugreifen weil du immer weisst zu welchem Thread welcher Post gehört.

Außerdem kannst du, wie es jedes Forensystem mittlerweile kann, dann auch zwischen den Darstellungsformen wechseln.

Trugschluss. Du musst sowieso für jeden Beitrag die Userid speichern und diese Daten aus der DB holen. Ob du nun noch ein Feld mehr ausliest oder nicht dürfte deine Performance nicht sonderlich nachhaltig beeinträchtigen.

__________________
"Alles im Universum funktioniert, wenn du nur weißt wie du es anwenden musst".

Manko10

Schlechter weil lahmer und auf Dauer umständlicher Ansatz. Nested Sets sind besser. Wirken zwar anfangs komplizierter, stellen sich hinterher aber als effektiver, schneller und einfacher zu handhaben heraus.

Beitrag editiert:
[…] Zu lahm

__________________
Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”

poli-tik

Das Problem mit den parentIds ist, dass man nicht vernünftig SELECTs definieren kann. Man greift dann zu starren Strukturen und behindert sich dann nur selbst.

Möchte man flexibel bleiben und beliebig viele Ebenen definieren können, kann man das mit nested sets bewerkstelligen. Die haben jedoch einen großen Nachteil. Arbeitet man mit ihnen, ist das sehr arbeitsintensiv.

Im Forum gibt es einige Einträge zum Thema nested sets und Alternativen. Ich würde LDAP vorschlagen.

nikosch

Ich wage mal anzumerken, dass Threadstrukturen ja eigentlich (IMHO) auf Antwort/Zitatverhalten beruhen und Beiträge damit nicht zwingend nur einen parent-Node besitzen. Damit sind weder Nested Sets noch ParentID geeignet.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--