fantast

Ich will ein Kommentarsystem in Thread-Form aufbauen. Hierbei stosse ich natuerlich auch schnell an die Limitationen, die RDBMS denjenigen auferlegtn, die versuchen hierarchische Daten zu speichern. Ueberall im Netz werden nun Nested Sets als die Loesung schlechthin angeboten.
Das moechte ich so nicht glauben, bedenke man doch einfach den sowohl Daten- als auch Transkationsoverhead der entsteht: Jeder Datensatz braucht zwei zusaetzliche Felder, und bei jeder strukturellen Aenderung muessen die bestehenden Datensaetze neu geschrieben werden.

Was gibt es also fuer Alternativen ? Wie performant ist eine rekursive Suche den Baum hinauf ? Ist die evtl. sogar mit Stored Procedures zu bewaeltigen ? Wie praktikabel sind Ansaetze wie der Materialized Path ?

Wer noch Links und Tips hat, bitte her damit !
f

__________________
Was ist validität?

Mister Ad

axo

die zwei zusätzlichen felder kannst du aus der speicherschätzung rausnehmen, der speicherverbrauch ist im vergleich zu den zu lesenden daten minimal - sind ja nur integers. und die nested sets gehen ebenfalls davon aus, dass im potenzbereich 10^n mehr lese- als schreiboperationen vorkommen, was realistisch ist. die optimierung läuft also auf 'etwas langsameres schreiben für deutlich schnelleres lesen' hinaus. für dein kommentarsystem ist das ganze also wirklich optimal.

es gibt noch ein 'frequent insertion' nested set, das zwischenräume zwischen den lft-rgt-indizes lässt und damit einige updates spart.

wo ist denn das eigentliche problem? ist das ganze zu einfach? gute lösungen sind immer einfach - daran erkennt man u.a. ihre güte.

gar nicht.
klar, wäre aber zu bezweifeln, ob das ganze wirklich schneller wird. rekursion bleibt rekursion. materialisierte views helfen manchmal, sind aber meist nur der ausweg aus einem schlechten datenbank-design oder beim rollup, und ein typisches beispiel vom speicher <-> laufzeit - spielchen.

du ersetzt im prinzip nur mathematische berechnungen (lft +- rgt etc ) durch stringvergleiche. speicher sparen dürftest du damit nicht, LIKE - und SUBSTR- abfragen dürften auch schlechter performen als indizierte lft-rgt-abfragen ... i woaß ned. so gut klingt das ganze nicht.