Forum - Aufbau



  • Hi,
    ich schreibe gerade eine Forensoftware in Php und verwende MySQL für die Datenbanken, doch haben sich mir zwei Fragen aufgeworfen:

    Zum Ersten geht es um die Struktur der Tabellen und ich wollte eure Meinung hören, welche der folgenden Varianten die Beste ist ...

    1. Eine Tabelle für die Beiträge, eine zweite für die Antworten -> schnelle Suche, aber groß und unübersichtlich.
    2. Eine Tabelle für eine Beitragsliste und dann für jeden Beitrag eine neue Tabelle -> übersichtlich, aber wahrscheinlich SEHR langsame Suche.
    3. Eine Tabelle für die Beiträge und dann z.B. 3 Tabellen für verschiedenen Beitragslängen -> schnelle Suche, wenig Speicherverbrauch, relativ schnelle Suche.

    Das zweite Problem ist die Speicherung der Texte in den Beiträgen. Wenn man LONGTEXT verwendet kommt man nur auf 65536 Zeichen, was zwar für die meisten Beiträge ausreichen sollte, aber dennoch eine nicht zu übersehende Grenze darstellt. Wie wird dies im Normalfall gelöst?
    Werden in MySQL dann eigentlich immer 64k pro Beitrag belegt, egal wieviel eingetragen wird?

    Danke

    M.T.



  • Spreche nun nur aus MSSQL, MS ACCESS und einfacher MySQL-Erfahrung. Werde auch nur erzählen wie ich es bei mir in der Arbeit erledigen würde (aus dem Bauch heraus). Wir haben schon wesentlich größere Datenbankprojekte abgeschlossen.

    So wie ich das verstanden habe soll die Struktur folgendermaßen ausschauen:

    Tabellen
    --------
    Benutzer
    Beiträge
    Fragen
    
    Aufbau
    ------
    Benutzer - 1:n - Fragen - 1:n - Beiträge
    

    LONGTEXT stellt schon wohl die richtige Wahl da. 64k ist eine Menge und sollte reichen. Natürlich könntest Du kleinere benutzerdefinierte Typen auswählen, Bsp. 2000 oder nur 5000. Schaue doch mal hier im Forum wie lang die längsten Beiträge sind.

    Unterschiedliche Tabellen für unterschiedliche Beitragslängen ist keine gute Idee. Dann hättest Du drei Beitragstabellen. Das ist Müll. 😉 Eine Tabelle pro Inhalttyp: Benutzer, Beiträge, Fragen, Dateien usw.

    Die Beitragsliste erhältst Du über SQL, so wie weitere Daten. SQL ist sehr mächtig, auch wenn MySQL natürlich mit MSSQL, DB2 oder Oracle nicht mithalten kann.

    Wichtig: 64k-Felder sind langsam und groß. In wie weit diese stets voll geschrieben werden liegt sicherlich an MySQL und müsstest Du mal testen. Lege doch mal eine Tabelle an und schreibe etwas Text (unterschiedlich viel) und notiere Dir die Änderungen.

    - Hoffe, hilft Dir etwas. 😉



  • Öhm ich wiederspreche euch zweien ja nur ungern *g* aaaber:

    Der Typ LONGTEXT fasst theoretisch 4 GB Daten, also 4.294.967.296 Buchstaben 😉
    Die von Mysql tatsächlich verwendete Größe beträgt bei LONGTEXT ($tatsaechliche_textlaenge+4) Bytes. Wenn du in so einem Feld also nur einen Buchstaben speicherst, dann belegt der auch nur 5 Byte. Auch sollte die Arbeit mit solchen Feldern nicht wesentlich langsamer sein als mit kleineren (natürlich vorausgesetzt, dass man keine 4 GB-Beiträge schreibt und die dann vom Server immer runterladen muss *g*)

    Übrigens:
    TEXT = max 65.536 Zeichen
    MEDIUMTEXT = max 16.777.216 Zeichen

    Zu den Tabellen: Ich würde eine für die Threads und eine für alle Beiträge nehmen. Dann kannst du die über IDs miteinader verknüpfen.

    Bloops



  • Ah, verdammt. War zu faul nachzuschauen. 😉



  • wenn du für jedes thema ne eigene tabelle anlegst, dann wirst narrisch 😉
    ich würd eine table nehmen, wo du reinschreibst, welche foren, die beschreibungen, wer mod ist, wieviele beiträge, aktuellster beitrag
    und eine table für die topics (posts). da musst dann halt folgende infos mitspeichern:
    general-id, topic id (also zu welchem topic der eintrag gehört), datum, autor, text, bearbeitungen (wann?)

    die general-id wird per auto-increment gemacht, für die topic id musst dir was überlegen (dürft aber nicht schwer sein). denke phpbb ist ähnlich aufgebaut 🙂



  • general_id??? neee... es gibt ne foren_id, ne topic_id und ne post_id. Die kann mann dann wunderbar alle miteinander verknüpfen.



  • Ich denke für Korbinian war general_id == post_id... 🙂



  • Ladt dir doch einfach mal das phpBB runter und schau dir an, wie es dort aufgebaut ist - oder auch andere Foren (gibt es ja zu Hauf)



  • LOL... oh *g* Na dann *general_id for president schild hochalten tu* 😃

    Aber ich versteh nicht, was man sich seiner Meinung nach bei der topic_id überlegen soll... Die wird auch einfach autoincrementiert...



  • hm, anscheinend hab ich mich misverständlich ausgedrückt:
    general_id = id des einzelnen postes
    topic_id = id des topics (themas) zu dem dieser post gehört. wird eigentlich nicht autoincrementiert. nur wenn einer ein neues thema erstellt (neues topic)



  • Ja eben, immer wenn einer ein neues Topic erstellt, also bei jedem INSERT in die Tabelle, denn wenn einer nur ein Posting verfasst, dann äußert sich das ja nur in einem UPDATE in der topic_table. 🙂



  • Benutzer
    --------
    ID
    Name
    
    Thema
    --------
    ID
    BenutzerID
    Bezeichnung
    
    Beitrag
    --------
    ID 
    ThemaID
    Titel
    Inhalt
    
    Durch die IDs verknüpfst Du die Felder miteinander. Ganz einfach.
    

    Sofern Du Dich für Datenbankprogrammierung näher interessierst, kommst Du nicht umher Dir ein gutes zulegen zu müssen. Nichts ist schlimmer als selbstgeflickte MySQL-Datenbanken. Vor kurzem durfte so eine Datenbank neustrukturieren. Es war furchtbar. 🙄

    Ergänzend: Natürlich fehlen in meiner Darstellung viele Felder wie Löschtermin, Erstelltermin oder Änderungstermin, sowie Ersteller usw. Aber das überlasse ich Dir.



  • OK, danke. Vorallem die Info, dass LONGTEXT nur genau die Textgröße belegt ist nützlich.

    M.T.


Anmelden zum Antworten