MySQL: Rekursiv

[BloodySword]

Hallo, ich habe ein ziemliches Problem. Undzwar schreibe ich gerade ein eigenes Forum. Ich kann aus verschiedenen Gründen kein fertiges nehmen, aber darum geht es hier nicht.

Ein Forum kann beliebig viele ineinander verschachtelte Unterforen haben.
Die Frage ist nun folgendes: Wie finde ich heraus, ob das Unterforum betreten werden darf, wenn ich nur die Unterforum ID habe? Ein Forum oder ein Unterforum bekommt ein rank_visible-wert. Ist dieser =4 bedeutet es, dass es nur Admins sehen dürfen.

Forum 1
Forum 2 ist in Forum 1 eingegliedert
Forum 1 hat rank_visible=4, forum 2 nicht.

Wie finde ich nun heraus, dass Forum 2 von einem User nicht betreten werden darf, weil ja Forum 1 nur für Admins ist?

Muss ich da alle rank_visibles rückwärts durch gehen, bis diese sich ändert?

lg

[DokuLeseHemmung]

Ja.
Man kann zwar rekursiv löschen (15 Ebenen tief), aber nicht SELECTen.
Du könntest alternativ auf "Nested Sets" umsteigen.

[BloodySword]

Zitat von DokuLeseHemmung

Ja.
Man kann zwar rekursiv löschen (15 Ebenen tief), aber nicht SELECTen.
Du könntest alternativ auf "Nested Sets" umsteigen.

Ich hab das jetzt so gelöst, dass ich eben damit lebe. :) Der Admin hat dann eben auch darauf zu achten, dass er die Rechteverteilung auch in den Unterforen richtig einstellt. Ich denke das ist kein Problem. Man könnte es auch als ein Feature betrachten, zumal man dann bestimmte Forenbereiche wieder öffnen kann.

Dabei bleibt nur die Frage wie ich das mache, dass dann das Forum mit Rank_visible=4 trotzdem gelistet wird, weil es irgendwo ein Unterforum hat, wo auch User mit einem schwächeren Rank willkommen sind... Ich denke darauf muss ich dann verzeichten. Man kann ja für den Fall auch den Link des Unterforums weiter geben. Außerdem wird dies in der Praxis eh extrem selten verwendet.

Was sind "Nested Sets"? Davon hab ich noch nicht gehört.

Edit:

CREATE TABLE `forum` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `order` bigint(20) NOT NULL,
  `parent_id` bigint(20) NOT NULL,
  `user_id` bigint(20) NOT NULL,
  `user_name` varchar(128) NOT NULL,
  `date_created` datetime NOT NULL,
  `date_edited` datetime NOT NULL,
  `ehit_count` bigint(20) NOT NULL,
  `is_closed` tinyint(1) NOT NULL,
  `rank_visible` tinyint(3) NOT NULL,
  `type` tinyint(1) NOT NULL COMMENT '0=Forum;1=Thread;2=Post;3=Spacer',
  `post_count` bigint(20) NOT NULL,
  `themes_count` bigint(20) NOT NULL,
  `latest_post_id` bigint(20) NOT NULL,
  `is_sticky` tinyint(1) NOT NULL,
  `is_top` tinyint(1) NOT NULL,
  `is_announce` tinyint(1) NOT NULL,
  `mods` varchar(255) NOT NULL,
  `title` varchar(255) NOT NULL,
  `content` text NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 ;

So sieht die Tabelle für das (gesamte!!) Forum aus.

Wie parent_id schon sagt, lässt sich damit alles Mögliche in einander verschachteln.
ehit_count ist kein Tippfehler. Dieses Feld wird gleichzeitig für die Anzahl der Edits bei einem Thread oder Post, als auch für die Anzahl der Hits bei einem Forum oder verwendet :).

Interesant wird es auch, wenn ein Post in einem Thread gemacht wird. Dann muss ich rückwärts die Struktur durchgehen und dort die Anzahl der Posts sowie die ID des neusten Posts zu aktualisieren. Ist aber kein Problem.

Ähnliches habe ich auch realisiert um den Pfad in dem der User sich gerade befindet anzuzeigen. :)

lg

[DokuLeseHemmung]

Was sind "Nested Sets"?

Du könntest Google oder irgendeine andere SUMA befragen...

[Domi]

nested sets ... guter Input! Aber werden die in der Praxis wirklich viel verwendet? Bisher hab ich mir das eigentlich immer "von Hand" zusammengebaut, ist halt die Frage, wie viel von der performance rüberkommt und ob das den Aufwand gerechtfertigt.

[DokuLeseHemmung]

Ist natürlich nervig, wenn man das selbst klöppelt. Aber es gibt ja einiges vorgefertigtes.
Z.B.: http://www.doctrine-project.org/docu...rarchical-data
Ist genial, damit ist es ein Kinderspiel.

Und die Leseperformance steigt mit der tiefe des Baumes, im Verhältnis zu binär Bäumen.
Und schwächelt beim ein/austragen von Blättern/Knoten.

[xabbuh]

Zitat von DokuLeseHemmung

Und die Leseperformance steigt mit der tiefe des Baumes, im Verhältnis zu binär Bäumen.
Und schwächelt beim ein/austragen von Blättern/Knoten.

Absolut, wobei die Schreibperformance in einem Forum sicherlich vernachlässigbar ist, so lange nur die Forenstruktur und nicht die Beiträge damit abgebildet werden. Auf der anderen Seite muss man sich aber auch fragen, ob die Forenstruktur wirklich so ausgeprägt sein wird, dass Lesezugriffe auf eine Nested Set-Datenstruktur merkbar schneller sind.

Gruß

[BloodySword]

Ich jedenfalls hab mich entschieden so weiter zu machen wie bisher. Ich denke das ist vollkommen ausreichend, nicht wahr? (Siehe Tabelle)

Es werden vielleicht noch die ein oder anderen Spalten entfernt oder hinzugefügt werden aber sonst sehe ich das ganze schon als stabil genug an.

BTW.: Weiß jemand von euch wie man eine Baumansicht mit Smarty rendert? Mit {foreach} wird das nicht gehen, ich müsste dann ja im template unendlich viele {foreach} schachteln.

lg

[Domi]

Zitat von BloodySword

BTW.: Weiß jemand von euch wie man eine Baumansicht mit Smarty rendert? Mit {foreach} wird das nicht gehen, ich müsste dann ja im template unendlich viele {foreach} schachteln.

lg

Rekursion ist das Zauberwort. Du kannst nämlich auch in Smarty so kleine Funktionen bauen, außerdem kannst du teilweise PHP-Funktion verwenden, denke da daran zu übrtprüfen mit empty(), isset() usw, geht alles einfach so in Smarty.

[BloodySword]

Ich schau mal in die Smarty-Doku oder mit Google. Wenn ich dort nichts finde komme ich nochmal auf euch zurück ^^'.

Vielen Dank!