Abfragelogik -> Verkettung

[Seikilos]

Also, Szenario ist, ich habe X Kategorien und X Unterkategorien, alles wird einer DB gespeichert, dabei Hilft auto_increment als ID ungemeint,
es gibt also ID, NAME, isSub( Link auf ID, wovon man Unterkategorie ist), in der Form

1 Ober   NULL
2 Kellner 2
3 Suppe 4
4 Essen NULL
5 Fisch 3

Was wäre hier eine effiziente Abfragelogik? Um jeweils die Zugehörigkeit darzustellen (es geht hier nicht um bessere Lösung, oder um Pear Nested Sets usw).

Die einfachste Methode (und auch ineffzienteste) wäre wohl
1. Abfrage von isSub is NULL mit ID, damit
gibts

[1 Ober]
[4 Essen]

jetzt kann man jeweils für beide Einträge eine Abfrage wo jeweilige ID=isSub ist:

[1 Ober][2 Kellner]
[4 Essen][4 Suppe]

dann weiter

[1 Ober][2 Kellner]
[4 Essen][3 Suppe][5 Fisch]

Ist das nicht eine ziemlich ineffiziente Abfrage? Da man für 5 Kategorien 4 Abfragen hat?

Wie gesagt, ich möchte nicht das Rad neu erfinden, dafür sind ja Nested Sets da, aber ich will die Theorie verstehen

[penizillin]

ich habe X Kategorien und X Unterkategorien

also hast du immer X^2 einträge? sagen wir - X und Y, beides elemente der menge der positiven ganzen zahlen

das ist ein klassisches "adjacency list model" (-> google), seine vernwendung ist meistens an die rekursion gebunden, und die ist immer performanzschädigend.

das ist aber bei großer auslastung erst problematisch. ist es denn hier der fall?

[Seikilos]

Unter Umständen, ich wundere mich, wie es Board denn lösen konnte, es gibt doch auch Subkategorien und rekursiv wurde es doch auch nicht performanceschädigend gelöst, oder?

[penizillin]

moderne boards geben ja auch die nachrichten "threaded" aus - d.h. du siehst immer nur die foren, dann nur die themen und dann nur die nachrichten eines themas. dabei kann man alle "elemente" EINES oberelement mit einer join-query ermitteln.

wenn du dich erinnerst, früher hatten die boards alle nachrichten "listed" ausgegeben - mit <ul> und <li>. das wäre über ALM gelöst den server zum glühen bringen.

[Seikilos]

Hab mich gerade über Nested Sets, oder sinnvoller bekannt alias Modified Preorder Tree Traversal reingelesen, per Zufall, da ich es nun verstehe, macht es Sinn. Das Pear:Nested Set package hat keine hilfreiche Doc, so dass ich anhand der Funktionen wohl kaum schlau geworden wäre-
Aber nun hab ich es, denke ich.

[penizillin]

http://pear.php.net/package/DB_Neste...mentindex.html

[Seikilos]

Das ist n bisschen mager
Das hat mir auch nicht geholfen, zu verstehen, was es kann oder tut

Auch Arnes Seite hat mir nicht viel geholfen.
Aber ich schreib es sowieso lieber selber, viel scheints nicht zu sein, ist ja nur geschiebe von zahlen