nicht angemeldet
Moin
das paßt gut zu meinen Ausführungen in </?m=18608&t=3166>:
Wieder ein solcher CPU/RAM - TradeOff.
Ja, aber unter den gegebenen Bedingungen, glaube ich doch dass das die beste Lösung ist. Nichts gegen eine schöne Hashtabelle, aber wenn man das selbst in PHP implementiert ist es höchstwahrscheinlich beträchtlich langsamer als die in PHP bereits eingebauten Funktionen, die wahrscheinlich exakt den selben Algorithmus benutzen, aber dafür schön kompiliert vorliegen. (Man kann jetzt natürlich zig Variationen machen. Zum Beispiel statt der Liste hinter jedem Hash-Index die Hash-Tabelle mit offener Verkettung benutzen - so wie wir es grade im Studium lernen - erkauft sich dabei etwas Geschwindigkeit, allerdings mit den Kosten dass die Hashtabelle voll ist, wenn sie voll ist, man vorher also genau wissen muss, wieviel Platz man braucht. Oder man nimmt B*-Bäume. Oder ... usw.)
Hier geht es aber kaum darum möglichst viele Daten möglichst gut im Speicher abzulegen, sondern es dürfte reichen wenn man nur die Daten die man wirklich braucht im Speicher hat. Geht man davon aus, dass die Datenbank alle ihre Daten bereits im Cache hat und die Zugriffe nur über indizierte Felder erfolgen (an dieser Stelle sollten drei Ausrufezeichen stehen, bitte bitte lege auch einen Index auf das Feld mit dem du die Datenbank abfragst, also hier wahrscheinlich die Nummer des Elternknotens) sollte die Datenbankabfrage kaum Rechenzeit verbrauchen und nur noch die Entfernung zur Datenbank einen beschränkenden Faktor darstellen. Da die Datenbank wahrscheinlich auf dem selben Host läuft, geht es hier also fast nur noch um das durch die Gegend kopieren im Hauptspeicher (ja, mit Zugriffen auf den Datenbankindex) was ungefähr - pi mal daumen - genauso schnell oder etwas langsamer abläuft wie die in PHP selbst programmierten Hashfunktionen. Mit dem eminenten Unterschied das vorher kein SELECT * FROM Tabelle nötig ist, sondern nur die Daten die der User braucht, ihren Weg in den Speicherbereich von PHP finden. Der User sollte natürlich nicht alle Bäume gleichzeitig ausklappen :)
Einen kleinen Haken hat die Sache noch: Wenn jemand den Baum mit dem sich dein Skript gerade beschäftig löscht, während es noch beim Datenzusammenkratzen ist, könnten sich Probleme ergeben. Hier ist dann eine etwas intelligentere Fehlerbehandlung gefragt (Im Zweifelsfall einfach nochmal von vorne anfangen) oder du musst die Tabelle für Schreibzugriffe sperren bevor du dich ans Werk machst.
Andere Fehler können natürlich auch mittendrin auftreten (etwa dass die Datenbank plötzlich keine Lust mehr hat) und dann ist es etwas unschön wenn dein Skript schon den halben Baum ausgegeben hat. Deswegen habe ich immer ganz gerne alle Datenbankabfragen am Anfang des Skriptes bevor jeglicher HTML-Code ausgegeben wird. Es sollte hier aber reichen wenn du deine Ausgabe erstmal in einen String schreibst und den nur ausgibst, wenn alles geklappt hat. Oder du aktivierst output_buffering (http://www.php.net/ob_start) und schmeisst den Buffer weg, wenn was schiefgeht.
so long...
--
Henryk Plötz
Grüße aus Berlin