Hallo Christian,

Wir reden aneinander vorbei, anders gefragt:

Stell dir vor wir lassen die Hashes der nten Stufe weg (die diesbezüglichen Schlüssel bleiben z.B. in der DB), und wir bauen nur einen  "perfekten" Hash der 2^16 häufigsten Suchbegriffe auf (z.B. mit dem Tool das Christoph erwähnte). Ist der Suchbegriff nicht im Hash wird er dann klassisch über binärbaum in der DB gesucht.

Wäre es dann von der Gesamtperformance nicht besser, wenn in über 95% der Fälle nur auf diesen Hash zugegriffen werden müßte?

(vorausgesetzt diese "perfekte" Hashfkt ist selbst performant, da seh ich den Haken...)

Natürlich hast du unter deinen Annahmen recht. Wenn das Vokabular ähnlich stark wachsen würde wie die Zahl der Postings würde mein Ansatz keinen Sinn machen. Dieses tut es aber IMHO nicht, weil keine Randomfunktionen posten sondern Deutschsprecher.²

Ich optimiere aber im Hinblick auf dieses Userverhalten!

weitere Diskussion duerfte nicht viel bringen. «Du glaubst mir ja eh
nicht!»

doch ich weiß zwar ad hoc nicht wieso der Exponent des Schlüssels in 2er Schritten wachsen muß, außer das Chips so organisiert sind, aber ich glaube dir unter deinen Annahmen.

Wieso brauche ich für 256 Einträge 32-Bit Schlüssel???

Der hoeheren Genauigkeit wegen. Die Genauigkeit muss doch hoeher sein als
in der ersten Stufe.

Allerdings wieso könnte ich - theoretisch - nicht mit diesem Perfekte-Hashfkt-Bastel-Tool nicht einen neuen Hash für 256 Einträge basteln??? (ausser das der overhead für die Funktion eventuell größer ist als die Tabelle?)

Ehrlich gesagt ich hätte sowieso ein Problem damit für 256 Werte einen Hash zu nehmen, deswegen sagte ich "geeignet Datenstruktur". Diese geeignete Datenstruktur kann auch teuer sein, weil sie selten gebraucht wird.

Tschau
 rolf

²Ich hätte noch erwähnen sollen das man zusammengesetzte Wörter auch in Einzelteile zerlegen sollte um ein gutes Ergebnis zu haben.