[Diskussion] Aufbau einer Datenbank für ein Webforensystem mit flachen Threads



  • Ich bin gerade dabei ein Webforensystem zu bastel, dabei stellt sich natürlich auch die Frage des Datenbankschemas.

    Mein aktuelles Schema ist noch recht mikrig, und ich wollte es erweitern um den Anforderung einer wachsenden Comunity mit Support für anonyme Poster auch bei mehr als nur ein paar dutzend Usern gerecht wird.

    Das aktuelle Schema hat folgende Tabellen vor:

    user
    groups

    forum
    - id
    - name
    - parent referenziert forum
    - moderators : rel auf user

    Thread
    - id
    - name
    - forum ref
    - user ref
    - ctime/mtime timestamps
    - ist_geschlossen bool

    Post
    - id
    - thread ref
    - ctime/mtime timestamps
    - user ref
    - text

    dieses Schema beinhaltet jedoch bei weitem nicht alle benötigten Daten, da man z.b. einiges an Logs und Statistiken benötigt und bestimmt auch den Wunsch hat einige Daten, die andernfalls durch recht teure Operationen generiert würden, oder sogar durch das löschen total veralteter Daten verfälscht würden zu Cachen

    Meiner Meinung muss noch folgendes rein:
    - Loging der Aktionen mit user + ip rein,
    - Caching von Post count für Foren/Threads,
    - Caching von Thread count in den Foren,
    - eine Tabelle für die erweiterten Profildaten

    nebenbei evtl noch so Sachen wie Cachen der gerenderten Post-texte und Indexinformationen um besser festzustellen auf welcher Seite sich ein Post befindet, da einige Populäre db's statt Sequenzen nur autoincrement haben, und somit Posts keine günstige Möglichkeit besitzen würden die aktuelle Seite festzustellen.
    (kann der db-interne Index Sachen wie count aller Posts im selben Thread mit kleinerer id, um die post-position im Thread festzustellen passend optimiern oder ist es besser da selber nen feld zu belegen ? )

    evtl. auch die Möglichkeit alternative Markups bei den Posts anzugeben (weil BBcode ist ned wirklich toll, nur üblich)

    ich hoffe das ihr noch einiges findet, an das ich nicht oder nicht korrekt gedacht habe

    mfg r0nny



  • Ich würde grundsätzlich das UI-Schema vom Basisforum-Schema trennen. Das heißt Dinge wie Markup-Replacements, Smilies, etc. gehören woanders hin.

    Dir fehlt noch "category" - oder willst du das auch über Subforen lösen? Dann kann man aber auch in der Kategorie posten?!

    Willst du tatsächlich den Status "Moderator" so eng binden? Ich würde da lieber ein Rechtesystem sehen dann hast du beim Erweitern viel mehr Möglichkeiten. Die dazu nötigen Tabellen hast du ja im selben IRC-Log in dem du mir +v gegeben hast :p

    Die Caches der Counter kannst du ganz einfach redundant in der jeweiligen Tabelle drüber speichern (also ein Attribut threadcount in forum).

    - ist_geschlossen bool

    Wieder so eine enge Bindung. Willst du da nicht eine Tabelle Status? Wie implementierst du das Verschieben von Threads? Bedenke, dass der Thread dann in 2 Foren existiert.

    BTW: Was spricht gegen BBCode - den kennt jeder, er ist einfach anzuwenden und bei guter Implementierung (hust, nicht die vom phpBB) auch imho sehr fein.

    MfG SideWinder



  • BTW: Wofür genau benötigst du groups? Du hast den Moderator ja ohnehin schon direkt eingebunden. Wenn du da eine Assoziativtabelle user<->forum hast kannst du auch gleich noch ein Attribut is_admin einbauen und brauchst kein groups. (Es sei denn du baust doch noch ein Rechte-System ein).

    MfG SideWinder



  • gruppen um besser festzulegen wer in den foren lesen/posten kann

    Moderatoren hab ich so eng angebunden, da man dann mit sehr wenig aufwand und sehr geringen overhead an daten in der db checken kann ob ein user die entsprechenden moderator-operationen (editiern/verschieben/löschen) durchführen darf

    und alle foren die keine gruppe mit schreibrechten zugewiesen haben fungieren als kategorie

    fehlende leserecht verstecken ganze foren/forenbäume

    der cache für die gerenderten posts kommt klar in ne extra tabelle

    das rechtesystem wollte ich recht simpel halten, da ich keinen bedarf für mehr als mods + kontrolle wer lesen/posten darf sehe

    -> fals du da noch ne sinnvolle erweiterung siehst, überzeug mich davon 🙂

    bbcode werde ich garantiert nicht abschaffen - aber ich hätte gerne bessere alternativen
    btw - ich hab bereits nen bbcode-parser gebastelt, der besser als der von phpbb ist

    ich sehe ned so ganz warum ein thread in 2 foren existieren sollte - also warum sollte er ?



  • und alle foren die keine gruppe mit schreibrechten zugewiesen haben fungieren als kategorie

    Das heißt es ist möglich das innerhalb eines Forums wieder ein paar Kategorien zu finden sind. Nicht wie hier, wo es derzeit nur Kategorien auf Toplevel gibt?

    der cache für die gerenderten posts kommt klar in ne extra tabelle

    ?! Ja, klar.

    -> fals du da noch ne sinnvolle erweiterung siehst, überzeug mich davon

    Du bekommst plötzlich ein Artikelforum und möchtest den Korrekturlesern ein paar eigene BBCode-Tags bieten die nur in dem bestimmten Forum einsetzbar sind? 😉 Nein, lass es einfach. Du hast ja mal was von lightweight gesagt.

    ich sehe ned so ganz warum ein thread in 2 foren existieren sollte - also warum sollte er ?

    (Du plänkst ja ;)) - siehst du doch an unserem Forum hier. Ein Thread wird verschoben und bleibt sowohl im alten als auch im neuen Forum erreichbar. Beide referenzieren allerdings auf ein und denselben Thread.

    MfG SideWinder



  • SideWinder schrieb:

    Das heißt es ist möglich das innerhalb eines Forums wieder ein paar Kategorien zu finden sind. Nicht wie hier, wo es derzeit nur Kategorien auf Toplevel gibt?

    ja !

    volkard brachte im chat auch noch ne weitere nette idee
    man legt noch mal ne extra tabelle mit : relation von forum auf forum an, und kann damit ein netz an sinnvollen verlinkungen erzeugen, und dann auf passende unterforen in anderen kategorien linken

    SideWinder schrieb:

    -> fals du da noch ne sinnvolle erweiterung siehst, überzeug mich davon

    Du bekommst plötzlich ein Artikelforum und möchtest den Korrekturlesern ein paar eigene BBCode-Tags bieten die nur in dem bestimmten Forum einsetzbar sind? 😉 Nein, lass es einfach. Du hast ja mal was von lightweight gesagt.

    ich wollte sowiso den bbcode parser etwas refactoren und als klasse machen - dann kann man andere tagsets übergeben
    den mit dem anderen tagset benenn ich dann etwas anders und limitier ihn auf authoren und korrekturleser - schon passt es

    SideWinder schrieb:

    ich sehe ned so ganz warum ein thread in 2 foren existieren sollte - also warum sollte er ?

    (Du plänkst ja ;)) - siehst du doch an unserem Forum hier. Ein Thread wird verschoben und bleibt sowohl im alten als auch im neuen Forum erreichbar. Beide referenzieren allerdings auf ein und denselben Thread.

    mir wäre ein threadtyp, der als weiterleitung funktioniert lieber als eine : relation
    ich denke mal das sollte kein problem darstellen, und da die mtime bei dieser weiterleitung nicht geupdated wird würde sie auch recht schnell aus der liste der threads herauswandern, während der echte thread im richtigen forum so lange oben bleibt wie nötig



  • neues schema:

    user
    group

    profile
    * id = pk + ref auf user
    * n paar felder für sachen wie icq, homepage und den ganzen informationskram
    * anzahl der posts

    Forum
    * name
    * parent ref auf forum
    * readers : ref auf group
    * writers : ref auf group
    * moderators : ref auf group
    * links : ref auf forum

    Thread
    * titel
    * forumref
    * userref
    * username ( wird gesetzt wenn userref auf den anon user zeigt)
    * c/mtime
    * kind - eins von moved movedref, normal, article
    * moved_to ref thread nullbar
    * is_closed

    *** über die letzten beiden bin ich mir ned so sicher

    Post
    * userref
    * username
    * threadref
    * text
    * markuptype

    LOG:
    * action -> create alter delete
    * object_kind
    * object_id
    * userref
    * ip
    * timestamp

    da fehlen noch die cache-tabellen, aber ich denke mal das ist recht komplett - es kann jedoch sein das weitere tabellen für die suchfunktion nötig werden


Anmelden zum Antworten