nicht angemeldet
Hi Daniela,
Es gibt hier zwar Möglichkeiten mit PostingIDs wie
ThreadID.Posting.Posting.Posting...
zu arbeiten um die Hierarchie zu speichern, dafür muss die ID dann
aber als String gespeichert werden und von einem Script gemäss
Punkten in dem String richtig geparst werden, die Reihenfolgte stimmt
jedoch schon direkt aus der Datenbank und ein aufwändiger
Sortiervorgang ist nicht nötig.
Das ist jetzt die Stelle, wo die theoretische Modellierung auf die Realität trifft. Denn genau das ständige Parsen der Strings möchte man an dieser Stelle dringend vermeiden - der Thread soll bereits sortiert abgespeichert werden.
Also muß der "Pfad" des Postings ein sortierbarer Schlüssel sein. Das ist im Falle der obigen Darstellung aber nur dann der Fall, wenn
a) die "Spalten" voneinander getrennt angesprochen werden oder
b) die "Spalteninhalte" durch Werte gleicher Länge dargestellt werden.
Fall a) wäre ganz gruselig - wir wollen ja ganz bestimmt keine Datenstruktur haben, welche pro Thread-Tiefe eine Tabellenspalte verbrät (erstens limitiert das 'hart' die mögliche maximale Tiefe eines Threads, zweitens kostet es massenhaft Platz).
Fall b) wäre schon eher machbar, aber auch nur unter Randbedingungen.
Nehmen wir mal an, wir hätten eine festgelegte Maximalzahl von Sohn-Knoten pro Verzweigungstiefe, welche aufgrund einer Analyse des Datenmaterials erschlossen werden kann - wir hatte noch nie mehr als (beispielsweise) 47 Antworten auf derselben Ebene, also wird 99 eine Einschränkung sein, die niemandem wirklich weh tut. In diesem Falle wäre jede Posting-Bezeichnung als String aus zwei Ziffern darstellbar, und der gesamte String wäre sortierbar. (Mit etwas mehr Übersetzungsaufwand läßt sich natürlich dieser Mini-Integer in ein Byte codieren und aus der Folge der Posting-Bezeichner ein Binär-String konstruieren, welcher dieselbe Sortierbarkeits-Eigenschaft besitzt, mehr Werte darstellen kann und halb so viel Platz kostet.)
Trennzeichen zwischen den Ebenen brauchen wir dann natürlich keine.
Was wir immer noch bräuchten, wäre eine maximale Thread-Tiefe. Allerdings nicht als harte Grenze, sondern möglicherweise nur als weiche.
'Viele' Threads werden eine bestimmte Tiefe nicht überschreiten - raten wir mal eine Tiefe, die für 70-85% der Threads ausreichen würde, und reservieren den Platz für entsprechend lange sortierbare Thread-Schlüssel. (Über die uns im Wesentlichen bekannte Verteilungsfunktion der Thread-Tiefen wissen wir gleichzeitig, wieviel Luft wir in diesem Indexbaum mitschleppen.) Was aber tun, wenn jemand einen tieferen Thread erzeugt? Nun, niemand zwingt uns dazu, eindeutige Schlüsselwerte zu verwenden! Das heißt: Ab einer bestimmten Tiefe des Threads werden alle Postings denselben Schlüsselwert haben - und wir werden auf Anwendungsebene nachsortieren müssen. Such is life - es liegt an den vorhandenen Ressourcen, ob dieser Effekt in nennenswert vielen oder nur in ganz wenigen Fällen zum Tragen kommen wird.
(Nichts wesentlich Anderes liegt der Idee zugrunde, eine Phrasensuche mit einer Indexsuche und nachgeschaltetem Filter zu realisieren.)
Letzten Endes wäre meine bevorzugte Implementierungsmethode also womöglich gar ein Hybrid-Modell zwischen ganz verschiedenen Darstellungstechniken. Den Trade-Off zwischen den Vor- und Nachteilen zweier Ansätze würde ich versuchen, zu lösen, indem ich das mir genehmere Verfahren in den meisten Fällen und das alternative in den abstrusen Sonderfällen zum Einsatz bringe.
Um so sorgfältiger muß ich natürlich vorher die anfallenden Daten kennen - denn wenn am Ende das weniger performante Modell in 70% der Fälle zum Einsatz kommt, dann hat die Lösung ihre Aufgabenstellung verfehlt ...
Viele Grüße
Michael