Nested Sets vs. Rekursive Abfrage

[Linda]

Hallo Forumer,

kann mir bitte jemand die Vorteile bzw. Nachteile der zwei im Betreff aufgelisteten Methoden erläutern? Wie baue ich am besten eine baumartige Forumstruktur auf?

Ich habe mittlerweile beide ausprobiert und bin mir nicht sicher, welche die performanteste (die eleganteste) ist.

Vielen Dank.
Linda.

[Eternius]

Hallo,

wie hast du den welche ergebnisse ermittelt?

gruss

[Linda]

wie hast du den welche ergebnisse ermittelt?

Das Handling ist bei rekursiver Abfrage für mich einfacher. Nested Sets sind komplizierter zu händeln und zu verstehen :). Die Performance konnte ich leider mangels Datensätze nicht aussagekräftig testen.

Es stört mich auch, dass ich bei Nested Sets bei jedem neuen Beitrag die anderen Beiträge updaten und ein Lock auf die Datenbank setzen muss. Andererseits frage ich mich, warum existiert diese Methode überhaupt -> welche Vorteile hat sie?

[Eternius]

Hallo,

[IMHO]
für mich gilt: "Wartungsfähigkeit" steht über allem anderen.
Aussnahmen bestätigen die Regel.
Vor allem bei Arbeit im Team.
[/IMHO]

gruss

[Carsten]

moin!

Es stört mich auch, dass ich bei Nested Sets bei jedem neuen Beitrag die anderen Beiträge updaten und ein Lock auf die Datenbank setzen muss. Andererseits frage ich mich, warum existiert diese Methode überhaupt -> welche Vorteile hat sie?

NestedSets sínd ideal fuer komplexe Navigationsstukturen, die nicht oft geaendert, aber oft ausgelesen werden. Du kannst hier mit einem select die komplette Navigationsstrukur oder aber auch nur Teile auslesen.
Fuer ein Forum oder Board sind sie denkbar ungeeignet, da der Server irgendwann unter der Last der Posting zusammenbrechen weurde. Da die Querys der Updates immer groesser werden und die Dauer fuer die Updates immer länger... Und ein Board fuer 30 sec zu blockieren, um einen einen Betrag zu schreiben kann doch nicht richtig sei, oder?

Bei einer Navigation schaut es da anders aus - wer bekommt es schon mit, wenn man 30sec nicht in die Datenbank schreiben kann, wenn die user doch eh nur die Daten auslesen...

c ya
Carsten

[Frank (no reg)]

Hi,

das kommt auf die Implementierung der NestedSets an, wenn du
natürlich _das_ Forum als Baum betrachtest, kann es zu von dir
beschriebenem Verhalten (30sek pro Update) kommen.

Denk am besten einfach noch mal nach, dann kommst du sicher auf
eine praktikablere Lösung.

Gruß, Frank

[Carsten]

moin!

Denk am besten einfach noch mal nach, dann kommst du sicher auf
eine praktikablere Lösung.

klar gibt es andere Loesungen - ich wollte nur zeigen, fuer was die Nested Sets sehr gut zu gebrauchen sind. Fuer Foren oder Boards sind sie aber auf Grund der Sruktur eigendlich ungeeignet.
Gibt es denn Boards, NestedSets einsetzen?

c ya
Carsten

[Frank (no reg)]

Yo!

ich meinte eine praktikablere Lösung mit NestedSets ohne 30sek
die Tabelle oder Zeilen zu locken. Es ist eine Betrachtungsweise

• Forum = Baum / Thread = Ast
  oder
• Forum = Wald / Thread = Baum

Da in einem Thread niemals _sooooo_ viele Beiträge existieren,
dass die zwei notwendigen Updates bei NestedSets wirklich ins
Gewicht fallen würden reduziert sich der Updateaufwand gewaltig.

Ich kenne kein Forum wo ich weiß, dass es mit NestedSets läuft,
aber ich beschäftige mich mit Foren auch nicht sooooo sehr. :-)

Der Vorteil bei NS liegt eindeutig auf dem Read, klar, das liegt
auf der Hand.

Bis denn dann, muss mal langsam meine Mittagspause beenden ;-)

Frank

[Frank (no reg)]

Hi,

mit Handling meinst du, du schickst also recht häufig Queries hin
basierend auf dem jeweils aktuellem Punkt. Dann kommen da innerhalb
kurzer Zeit sehr viele ähnlich gelagerte Anfragen auf die Datenbank
zu. Das sollte sauber programmiert werden, damit nicht noch
irgendwelche Cursors geöffnet bleiben, wenn du den Ast im Baum
wechselst. Stored Procedures empfehlen sich in diesem Fall sehr,
da deine Abfragen gut parameterisierbar sind. Ob du SPs einsetzen kannst, entscheidet dein DBMS (MS SQL Server, Oracle etc).

Bei Nested Sets kannst du alle Informationen für einen Teilbaum
aufeinmal selektieren und laden, macht weniger Zugriffe und nur
minimal länger geöffnete DB-Cursors.

NestedSets zu verstehen ist nicht das Problem, eher zu lernen diese
Technik optimal einzusetzen.

Du schreibst, dass du für jeden Beitrag die "anderen Beiträge
updaten" musst. Ja, das ist die Kehrseite der NestedSets: erhöhter
Aufwand beim Schreiben. Aber überlege doch mal: Welche Beiträge
musst denn updaten, alle im Forum??

Gruß, Frank

[Tom]

Hello,

Die performateste ist sicher eine, die sich in gewissen Grenzen hält.

AA.
 AA.01.
 AA.02.
  AA.02.01.
AB.

Wenn Du die Treads so aufbaust, hast Du zwei Beschränkungen:

• Die Schchtelingstiefe der Threads ist begrenzt durch die Stringlänge
• Die Anzahl der Unterthreads ist begrenzt durch den Zeichnsatz, hier
    also z.B. 65635 pro Ebene.

Nun muss man sich so ein Forum nur mal anschauen. Welche Tiefe hatte denn hier der tiefste Thread?

Nested Sets lassen sich nur schwer wieder reparieren.
Rekursive Abfragen benötigen sehr viel Power für Selects.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Linda]

Nun muss man sich so ein Forum nur mal anschauen. Welche Tiefe hatte denn hier der tiefste Thread?

So viel Tiefe brauche ich nicht :)

Nested Sets lassen sich nur schwer wieder reparieren.

Wenn die Applikation stimmt - sollte nichts kaputt gehen.

Rekursive Abfragen benötigen sehr viel Power für Selects.

Hat es ein deutlichen Einfluss auf die Performance? Ich rede hier nicht von Millisekunden, sondern von Sekunden. Gibt's da irgendwelche Richtwerte?

Danke.

[Andreas-Lindig]

Hat es ein deutlichen Einfluss auf die Performance? Ich rede hier nicht von Millisekunden, sondern von Sekunden.

Ich glaube das ist relevant, wenn es um soundsoviele tausend Anfragen pro Sekunde geht. Für die einzelne Anfrage ist das wohl eher egal, sofern Dein Forum nicht die Gespräche der Menscheit beherbergt ;-)

Gibt's da irgendwelche Richtwerte?

keine Ahnung, aber NestedSets gelten in der Abfrage als ultra-schnell. Dafür wurden sie soweit ich weiß erdacht. Den Nachteil des umständlichen (und langsamen!) Upddates nimmt man dafür in Kauf.

Gruß, Andreas