Datenbank für ein Forum

[Eres85]

Ich will ein Forum schreiben und bin mir irgendwie noch nicht so ganz klar über ein vernünftiges Datenbankkonzept.

Die Überlegung geht in die Richtung:

Eine Tabelle anzulegen für die Kategorien meines Forums, z.B. Prolog, Vorstellungen, Veranstaltungen, Taverne, OffTopic.

Eine zweite Tabelle zu verwenden um die jeweiligen Themen zu speichern, also: das Thema, in welcher Kategorie das Thema steht, den Verfasser, ein Erstellungsdatum, den Einleitenden Text des Verfassers.

Und dann für jedes Thema eine Antwort-tabelle in der gespeichert ist, der Name der antwortenden Person, das Thema, ein Datum wann die Antwort geschrieben wurde und der Kommentar.

Allerdings graust es mir vor dieser Lösung ein wenig, da ich eben pro Thema eine Antwort-Tabelle erzeuge, ergo habe ich mal 600 Themen im Forum, habe ich auch 600 (Antwort)Tabellen in der Datenbank, wobei 600 Themen nicht gerade viel sind und dies natürlich nicht gerade zur Übersichtlichkeit meiner Datenbank beiträgt. Zur Perfomance will ich garnichts sagen, dort kenne ich mich zu wenig aus, aber ich kann mir gut vorstellen, dass eine solche Anzahl von Tabellen nicht gerade zuträglich ist.
Leider habe ich im Web zu diesem Thema bisher sehr wenig gefunden und finde bisher auch selbst keine bessere Lösung, vielleicht stehe ich ja auf dem Schlauch, oder machen IT Profis das auch so?
Wäre für jede Hilfe dankbar

[Frank (no reg)]

Hallo,

ich könnte jetzt hier ne halbe Bibel schreiben ...

Bitte nimm für gleichformatige Daten auch dieselbe physikalische Struktur! D.h. wenn eine Antwort (bzw. ein Beitrag) immer die gleichen Attribute hat (Ersteller, Datum, Bereich, Text) dann sollte sie bzw. er auch in der selben Tabelle gespeichert werden. Es gibt keinen vernünftigen Grund dies über mehrere Tabellen auszudehnen. Die Identifizierung, welcher Beitrag zu welchem anderen Beitrag gehört, kannst du über Fremdschlüsselbeziehungen auf dieselbe Tabelle gewährleisten. Zum Bleistift so:

  
CREATE TABLE Beitraege (  
  ID bigint  NOT NULL IDENTITY(1,1) PRIMARY KEY  
  ,Ersteller varchar(255) NOT NULL  
  ,Text varchar(max) NOT NULL  
  ,ErstellDatum datetime NOT NULL  
  ,Forumskategorie varchar(255) NOT NULL  
  ,IstErstbeitrag bit NOT NULL  
  ,AntwortAufThema bigint NULL  
  ,AntwortAufBeitrag bigint NULL  
  ,CONSTRAINT FK_Parent FOREIGN KEY (AntwortAufBeitrag)  
   REFERENCES Beitraege (ID)  
  ,CONSTRAINT FK_Them FOREIGN KEY (AntwortAufThema)  
   REFERENCES Beitraege (ID)  

Das Beispiel ist in T-SQL (für MS SQL Server 2005) und muss für MySQL ggf geändert werden. Darüberhinaus ist es in mind. 2 Fällen nicht normalisiert (für den Zweck der Veranschaulichung ist dies jedoch Wurst²). Und es gibt mindestens noch 10 andere Implementierungsmöglichkeiten.

Übrigens, was unterscheidet bei dir  ein "Thema" von einer "Antwort"? Wenn du genauer darüber nachdenkst: primär gar nichts, sekundär vielleicht ein paar Attribute / Flags (die dann für "Antworten" einen Default-Wert annehmen könnten oder NULL bleiben)

Und ausserdem, warum nimmst du nicht etwas, was es schon gibt? Vom Neuerfinden des Rades wirst du nicht reich (obgleich du das vielleicht gar nicht willst ;)). Für die Erweiterung des eigenen Horizontes ist es hingegen schon noch okay.

Grüsse,
Frank

[King^Lully]

Und dann für jedes Thema eine Antwort-tabelle in der gespeichert ist, der Name der antwortenden Person, das Thema, ein Datum wann die Antwort geschrieben wurde und der Kommentar.

Sowas wäre falsch.

Allerdings graust es mir vor dieser Lösung ein wenig, da ich eben pro Thema eine Antwort-Tabelle erzeuge, ergo habe ich mal 600 Themen im Forum, habe ich auch 600 (Antwort)Tabellen in der Datenbank, wobei 600 Themen nicht gerade viel sind und dies natürlich nicht gerade zur Übersichtlichkeit meiner Datenbank beiträgt.

Du versuchst Datensätze durch Tabellen zu ersetzen, sowas endet tatsächlich dann irgendwann an den Kapazitätsgrenzen des RDBMSs.

Leider habe ich im Web zu diesem Thema bisher sehr wenig gefunden und finde bisher auch selbst keine bessere Lösung, vielleicht stehe ich ja auf dem Schlauch, oder machen IT Profis das auch so?

Du musst die beteiligten Entitäten identifizieren, bei einer Schule wären das z.B.: "Schüler", "Lehrer", "Klassen", "Unterrichtsfächer", "Stundenpläne" etc.

Welche Entitäten spielen wohl in einem Forum oder Board eine Rolle?

(Wenn Du nicht so, also mit dem Datendesign und den oben beschriebenen Vorüberlegungen anfängst, bekommst Du Probleme.)

[rob]

Hi!

Allerdings graust es mir vor dieser Lösung ein wenig, da ich eben pro Thema eine Antwort-Tabelle erzeuge, ergo habe ich mal 600 Themen im Forum, habe ich auch 600 (Antwort)Tabellen in der Datenbank

So würde ich das nicht machen.
Sinnvoller wäre in den meisten Fällen wohl nur eine Tabelle für alle Antworten.

Ich will ein Forum schreiben und bin mir irgendwie noch nicht so ganz klar über ein vernünftiges Datenbankkonzept.

Es gibt genug gute OpenSource-Boards und -Foren.
Du kannst dir einfach was runterladen und dir anschauen, wie das dort gemacht wird.
Auch dieses Forum hier steht unter einer freien Lizenz. Du kannst dir den Code runterladen.
Auf vielen Websites setze ich das PHPBB2 ein.
Ich finde, daß dieses auch recht schön programmiert ist. Auch das könntest du dir runterladen und dir die Datenbankstruktur anschauen.
Wenn man Programmieren lernen will, dann hilft es in jedem Fall, wenn man sich fremden Code anschaut und sieht, wie andere ein bestimmtes Problem angehen.
Ich finde, daß das PHPBB recht gut programmiert/strukturiert ist und daher ein recht gutes Beispiel für dich sein könnte.

Schöner Gruß,
rob