✔ Baumstruktur in Datenbank eintragen

[splasch]

Zur Info, es heisst "Performance" - Wieso ist das Nested-Set-Modell bei Änderungen viel langsamer?
Nur weil bei Änderungen an mehreren Datensätzen die left und right Werte angepasst werden müssen?
Sorry, aber das ist je nach Änderungsgrad mit zwei SQL-Befehlen erledigt.

Das sag schon der Reihne Menschenverstand.Wenn die Datenbank nur 1 Datensatz ändern muß oder (Nested-Set-Modell) 100000 Datensätze umschreiben muß je nach dichte eben der Baum struktur kann nur langsamer sein. Je mehr zu tun ist um so länger braucht man auch dafür auch wens ein Pc ist.

Dann scheinst du das Modell nicht verstanden zu haben..

Anscheinend hast du dann auch nicht genau den Artikel gelesen.

[Zitat auf dem Artikel link :http://www.klempert.de/nested_sets/artikel/#kap6]

Denn im schlimmsten Fall müssen bei der Einfügoperation die LFT-/RGT-Werte aller bestehenden Knoten verändert werden. Dies wirkt sich natürlich insbesondere bei sehr komplexen Bäumen negativ auf die Performance aus

[Ende Zitat]

Wenn du sauber programmierst und das solltest, egal auf welchem Fundament dein Baum aufbaut, dann wird dir auch kein "Schreibfehler" passieren.
Stell dir vor, bei deiner Technik stürzt der Server ab - dein Baum würde ebenso fehlerhafte Daten aufweisen. Also ist dein Argument nur von den Haaren herbeigezogen und fällt somit nicht ins Gewicht.

Es ist ein unterschied ob jetzt nur 1 Menü punkt im Baum nicht geht oder der ganze Baumstam nicht abrufbar ist.
Zudem ist bei der kurzen Schreibzeit die Chance geringer das was nicht geschrieben wird als wenn alles in langer Zeit umgeschrieben werden muß.

Daher sind nicht Meine Argumente herbeigezogen sondern deine aus der Luft genohmen ohne irgendeinen standhaften halt.

Mfg Splasch

 

[Matthias Reitinger]

Das sag schon der Reihne Menschenverstand.Wenn die Datenbank nur 1 Datensatz ändern muß oder (Nested-Set-Modell) 100000 Datensätze umschreiben muß je nach dichte eben der Baum struktur kann nur langsamer sein. Je mehr zu tun ist um so länger braucht man auch dafür auch wens ein Pc ist.

Anscheinend hast du dann auch nicht genau den Artikel gelesen.

[Zitat auf dem Artikel link :http://www.klempert.de/nested_sets/artikel/#kap6]

Denn im schlimmsten Fall müssen bei der Einfügoperation die LFT-/RGT-Werte aller bestehenden Knoten verändert werden. Dies wirkt sich natürlich insbesondere bei sehr komplexen Bäumen negativ auf die Performance aus

[Ende Zitat]

Du hättest den Absatz ruhig noch zu Ende zitieren können, da du nämlich so einen wichtigen Aspekt unterschlagen hast: „Da in den allermeisten Anwendungen aber der lesende Zugriff sehr viel häufiger ist als der schreibende, braucht uns dies nicht weiter zu verunsichern.“ Veränderungen am Baum können also langsamer ausfallen, Leseoperationen dagegen sind schneller. In vielen Anwendungen treten Lesevorgänge (z.B. beim Abrufen der Produktkategorien eines Shopsystems) um mehrere Größenordnungen häufiger auf als Veränderungen (z.B. Hinzufügen einer neuen Kategorie), weshalb sich das Nested-Sets-Modell hier rechnet.

Zudem ist bei der kurzen Schreibzeit die Chance geringer das was nicht geschrieben wird als wenn alles in langer Zeit umgeschrieben werden muß.

Ein Datenbanksystem, das keine Datenintegrität garantieren kann, gehört sowieso ausgewechselt. Das ist also kein Argument für oder gegen eine der Vorgehensweisen.

Grüße,
Matthias

 

[chainy]

Du hättest den Absatz ruhig noch zu Ende zitieren können, da du nämlich so einen wichtigen Aspekt unterschlagen hast: „Da in den allermeisten Anwendungen aber der lesende Zugriff sehr viel häufiger ist als der schreibende, braucht uns dies nicht weiter zu verunsichern.“

Stellt sich jetzt nur die Frage, warum er diesen wichtigen Aspekt weggelassen hat. Jede Technik weist früher oder später ihre Vor- bzw. Nachteile auf, in diesem Fall ist wohl davon auszugehen, dass aus Sicht der Performance der Lesezugriff wichtiger ist als der schreibende.

 

[splasch]

Ich hab den Aspekt nicht aus einen Grung weggelassen sondern bin davon ausgegangen das Er denn Artikel auch gelesen hat und daher weiß was dort drin steht.

Hab Ihm nur auf eine Stelle Aufmerksam gemacht die Zuvor anders erwähnt wurde.

Siehe oben Ziat Frage: Wieso ist das Nested-Set-Modell bei Änderungen viel langsamer?
Nur weil bei Änderungen an mehreren Datensätzen die left und right Werte angepasst werden müssen?

Mfg Splasch

 

[chainy]

Du brauchst mich nicht auf den Inhalt des Artikels prüfen, ich kenne den Artikel ausgesprochen gut. Ich kenne auch die Tücken des Nested-Sets-Modell, nur sind diese nicht so gravierend wie die anderer Techniken, z.B. deiner.

 

[Sturmrider]

ohje, ich wollte mit meinem Post niemanden persönlich angreifen! :suspekt: die Stimmung die hier entstanden ist gefällt mir gar nicht... es wäre nett, wenn hier Provokationen und Angriffe auf die Intelligenz ausbleiben würden und die Sachverhalte ganz objektiv betrachtet würden (soetwas ist ja sicher möglich!)

Ich denke ich wüsste noch einen Aspekt beim parentId-Modell der bisher vergessen wurde, nämlich der Teil der für eine grafische Darstellung eines Baums von nöten ist. Zwar benötigt das parentId-Modell nur einen Zugriff auf die MySQL-Datenbank, jedoch müssen Sortierungen etc. per PHP durchgeführt werden, was meines wissens nach in den meisten Fällen Resourcenlastiger ist, als die Sachen schon vorher von MySQL gut durchsortieren zu lassen und dafür in PHP eine einfachere Darstellungsfunktion zu haben, die weniger Resourcenlastig ist.
Natürlich ist dies hier sehr stark abhängig von der Raffinesse des Programmierers, jedoch denke ich (aus eigener Erfahrung ->habe ja auch erst mit diesem Modell gearbeitet), dass dies auch auf diesen Fall zutrifft, egal wie gut der Programmierer ist.

Achso und noch als Anmerkung zu dem Problem mit dem Serverabsturz ich arbeite sowieso fast ausschließlich nur mit PDO und da ist das kein Problem, wenn der Server mal abstürzt -> die neu geschriebenen Daten werden erst freigegeben, wenn sie vollständig geschrieben wurden. Sollte vorher etwas passieren, werden sie einfach wieder in ihren Urzustand versetzt Außerdem bekomme ich durch PDO noch eine bessere Performance, da SQL-Abfragen gesammelt und parallel in mehreren Threads bearbeitet werden können ;-)


EDIT: Als ich eben mal bei Wikipedia "Nested Sets" nachgeschlagen habe bin ich dort auf einen Begriff: "Adjanzenzlistenmodell" gestoßen, kann mir jemand sagen, wie dieses Modell im groben aussieht bzw. richtig heißt (ich vermute mal "Adjazenzlistenmodell"), denn zum ersteren habe ich nichts gefunden...

 

[chainy]

Achso und noch als Anmerkung zu dem Problem mit dem Serverabsturz ich arbeite sowieso fast ausschließlich nur mit PDO und da ist das kein Problem, wenn der Server mal abstürzt -> die neu geschriebenen Daten werden erst freigegeben, wenn sie vollständig geschrieben wurden. Sollte vorher etwas passieren, werden sie einfach wieder in ihren Urzustand versetzt Außerdem bekomme ich durch PDO noch eine bessere Performance, da SQL-Abfragen gesammelt und parallel in mehreren Threads bearbeitet werden können ;-)

Guter Mann!

 

[Matthias Reitinger]

EDIT: Als ich eben mal bei Wikipedia "Nested Sets" nachgeschlagen habe bin ich dort auf einen Begriff: "Adjanzenzlistenmodell" gestoßen, kann mir jemand sagen, wie dieses Modell im groben aussieht bzw. richtig heißt (ich vermute mal "Adjazenzlistenmodell"), denn zum ersteren habe ich nichts gefunden...

Also ich finde ja, dass der Artikel in Wikipedia das recht gut erklärt:

Der klassische Ansatz zur Implementierung einer Baumstruktur in einer Datenbank ist das Adjazenzlisten-Modell. Hierbei wird zu jedem Knoten eine Referenz auf dessen Elternknoten abgelegt. Die Wurzel hat dabei keinen Verweis zu einem Elternknoten (das Feld ist mit NULL belegt); ein Blatt ist ein Knoten, zu dem kein anderer Knoten verweist.

Das entspricht genau dem Vorgehen, welches du im ersten Beitrag dieses Themas beschrieben hast.

Grüße,
Matthias

 

[splasch]

Ich denke ich wüsste noch einen Aspekt beim parentId-Modell der bisher vergessen wurde, nämlich der Teil der für eine grafische Darstellung eines Baums von nöten ist. Zwar benötigt das parentId-Modell nur einen Zugriff auf die MySQL-Datenbank, jedoch müssen Sortierungen etc. per PHP durchgeführt werden

Wenn du 1 Spalte in der Tabelle dazu machst kanst du die Sortierung über Sql machen.
Und wenn du noch Menü Punkte aus oder einblenden willst dann mach noch ein Spalte dazu. So muß man Menüpunkte nicht gleich löschen sonderen kann sie bei dedarf off oder an schalten bwz kann man einen Ganzen Menüzweig damit ausblenden.

Der Sql-befehl sieht dann so aus:

SELECT * FROM `kategorie` WHERE On_off='j' and `Parent` = '$vater'order by K_sort

(Schön einfach ohne viel Aufwand)

Mfg Splasch

 

[Sturmrider]

@Matthias Reitinger
oh, dass ist ja das selbe... ich habe den Abschnitt wohl nicht aufmerksam genug gelesen, sry -> wer lesen kann ist klar im Vorteil ^^°

@splasch
stimmt, da hast du recht mit einer visible-Funktion würde es theoretisch gehen. Vorausgesetzt wird jedoch, dass man beim Eintragen der Blätter/Zweige auch immer schön die Reinfolge einhält. Die parentIds müssen immer aufsteigend bzw. absteigend sortiert sein und nicht durcheinander geraten
aber problematisch wird das Modell, wenn man einen Zweig/Blatt verschiebt und die parentIds durcheinander geraten. Letzten Endes bringt eine visible-Funktion daher also nichts, das Problem würde weiterhin bestehen oder sehe ich das falsch?