Artikel in DB-> Nested Sets
- Themenstarter fungo
- Beginndatum
Nun nested sets is auf jedenfall der schnellere weg, was performance betrifft, nur leider sind die SQL queries halt ziemlisch kompliziert...
Parent model hatt gegenüber nestes sets einen geschwindigkeitsvorteil von faktor 300 oder so... müsst ich nachlesen...
path model is aber auch net viel besser als parent.. von daher...
Naja wie gesagt, musst du selbst entscheiden was dir wichtiger is... gute performance oder einfache SQL queries beim programmieren.
Parent model hatt gegenüber nestes sets einen geschwindigkeitsvorteil von faktor 300 oder so... müsst ich nachlesen...
path model is aber auch net viel besser als parent.. von daher...
Naja wie gesagt, musst du selbst entscheiden was dir wichtiger is... gute performance oder einfache SQL queries beim programmieren.
path und parrent sind 2 weitere modelle für das speichern von tree strukturen in datensatzbasierten datenbanken..
Nested Sets eigenet sich ideal für foren, da der geschwindigkeitsvorteil beim lesen den nachteil beim schreiben bei weitem aufwiegt.
Path funktioniert so das ein eintrag existiert wo die verschachtelung anhand der datensatz ID geordnet wird...
z.B.
1 ist die wurzel
1-2 is der erste subtree
1-3 is n weiterer subtree
1-2-7 is ein zweig von 1-2 und so weiter...
und beim parrent modell ist in einem feld immer die ID des übergeordneten gespeichert, nur ist hier beim lesen eine extrem hohe rekursion und damit unnötiger traffic erforderlich, was sich nachteilig auf die performance auswirkt....
Im PHP magazin war vor einiger zeit ein artikel wo ein vergleich drin is...
zuerst wurden die nachfahren des knotens 1 ermittelt.
Parrent und Path is dabei glatt durchgefallen, zeitfaktor 31 bzw. 27 vom nested sets modell. (Im vergleich, 1.217 sek bei parrent, 0.039sek bei nested sets.
der 2. test, die vorfahren von knoten ermitteln. hier ist nested sets um den faktor 2,5 langsamer gewesen (Im vergleich, parrent hier der schnellste, 0.002 sek, nested sets 0.005 sek)
der 3. test soll alle knoten der ersten ebene und die anzahl der nachfahren ermitteln... und hier rasselt parrent entgültig raus...35.275sek, im vergleich nested sets. 0.002 sek
was das schreiben betrifftz so ist nested sets aufgrund der architektur geringfügig langsamer als parrent oder path, aber da sich alles mit einer query erledigen läst hatt man keine performence nachteil dadurch. Dazu kann man die querry assynchron absetzen und so verhindern das man auf ein ergebnis warten muss das nicht existiert.
Nested Sets eigenet sich ideal für foren, da der geschwindigkeitsvorteil beim lesen den nachteil beim schreiben bei weitem aufwiegt.
Path funktioniert so das ein eintrag existiert wo die verschachtelung anhand der datensatz ID geordnet wird...
z.B.
1 ist die wurzel
1-2 is der erste subtree
1-3 is n weiterer subtree
1-2-7 is ein zweig von 1-2 und so weiter...
und beim parrent modell ist in einem feld immer die ID des übergeordneten gespeichert, nur ist hier beim lesen eine extrem hohe rekursion und damit unnötiger traffic erforderlich, was sich nachteilig auf die performance auswirkt....
Im PHP magazin war vor einiger zeit ein artikel wo ein vergleich drin is...
zuerst wurden die nachfahren des knotens 1 ermittelt.
Parrent und Path is dabei glatt durchgefallen, zeitfaktor 31 bzw. 27 vom nested sets modell. (Im vergleich, 1.217 sek bei parrent, 0.039sek bei nested sets.
der 2. test, die vorfahren von knoten ermitteln. hier ist nested sets um den faktor 2,5 langsamer gewesen (Im vergleich, parrent hier der schnellste, 0.002 sek, nested sets 0.005 sek)
der 3. test soll alle knoten der ersten ebene und die anzahl der nachfahren ermitteln... und hier rasselt parrent entgültig raus...35.275sek, im vergleich nested sets. 0.002 sek
was das schreiben betrifftz so ist nested sets aufgrund der architektur geringfügig langsamer als parrent oder path, aber da sich alles mit einer query erledigen läst hatt man keine performence nachteil dadurch. Dazu kann man die querry assynchron absetzen und so verhindern das man auf ein ergebnis warten muss das nicht existiert.
Nein es kommt nicht zu datenchaos und zwar deshalb weil die query normalweitese nacheinander abgearbeitet werden, aber wenn du auf nummer sicher gehen willst dann mach vorher ein LOCK TABLE und nacher ein UNLOCK TABLE und schon is das problem gelöst...
beispiele? guck dir mal die PEAR klasse zu nested sets an... http://pear.php.net/package/DB_NestedSet
das sollte dir eigendlich einen einblick geben wie sowas funktioniert...
