Hi Andreas,

Hat es dann keinen Sinn das man für besonders häufige Begriffe einen linearen Suchepfad verwendet? Also man muß sowieso die Suchbegriffe testen, und wenn es nunmal zu häufig ist dann sucht man linear. Oder hat das keinen Sinn?

das Problem ist, daß bei hinreichend großer Datenmenge die lineare Suche einfach gar nicht mehr funktioniert - egal, welche Eigenschaften die Suchbegriffe haben.

Das Ziel muß es sein, in vielen Fällen guter Suchbegriffe deutlich schneller zu werden als bisher und in wenigen Fällen schlechter Suchbegriffe zuverlässig zu erkennen, daß die Eingabe den Anwender nicht zu seinem Ziel führen wird.
Denn eine hohe Trefferzahl bedeutet ja nicht nur eine entsprechende CPU-Belastung - sie bedeutet insbesondere eine wahrscheinlich schlechte Qualität der Treffer. Es sei denn, es würde eine _sehr gute_ Ranking-Funktion angewendet ... aber selbst bei Google lasse ich mich von der Meldung, es gäbe mehrere tausend Treffer, dazu motivieren, weitere Suchbegriffe anzugeben, und das spült oftmals bessere Seiten nach oben, die ich vorher nicht gesehen hätte.

Meine Strategie wäre hier, zweigleisig zu fahren, also einerseits dem Anwender ab einer bestimmten Anzahl von Treffern zu sagen, daß seine Frage zu allgemein gestellt war (wie wir das hier im Forum ja auch oft genug tun ;-), und andererseits natürlich wirklich an einer Ranking-Funktion zu arbeiten und auszuprobieren, ob diese in der Realität zufriedenstellende Ergebnisse zu erträglichen Kosten liefern kann.

Und nochwas, hat es keinen Sinn für die Suche 1 GB extra RAM zu besorgen, und die Tabellen im RAM zu halten? Denn mehrere 100 MB(und wenn man das mit den Teilstrings macht werden das _einige_ 100, wobei man diese Tabelle wohl lieber auf der Platte ist, denn irgendwann sind sind auch 1 GB voll ;-)) auf der Platte zu durchsuchen ist IMHO übel!

Im Prinzip hast Du recht.

Andererseits: Wie viele Archivsuche-Anfragen gehen denn wirklich über das gesamte Archiv? Haben wir da eine Statistik, Daniela (oder Christian)?
Es hat sehr wohl einen Sinn, wie die Häkchen im Such-Formular vorbelegt sind - solange der Anwender daran nichts ändert (was ein DAU hoffentlich nicht tun wird - das umfangreiche Formular _darf_ ein bißchen abschreckend wirken, finde ich ;-), wird _sehr_ viel weniger als das ganze Archiv durchsucht.

Moment, ich schaue gerade mal nach:
 [X] SELFHTML V8.0      (  4.77 MB)
 [X] Feature-Artikel    (  1.50 MB)
 [X] Link-Verzeichnis   (  0.09 MB)
 [X] Forums-Archiv 2003 (  6.13 MB)
 [ ] Forums-Archiv 2002 (140.39 MB)
 [ ] Forums-Archiv 2001 ( 31.75 MB)
 [ ] Forums-Archiv 2000 ( 49.43 MB)
 [ ] Forums-Archiv 1999 ( 31.17 MB)
Verfügbar sind also 265,23 MB, durchsucht werden aber nur 12,49 MB - das sind gerade mal 4.7% des Datenbestandes! Aber die besten Seiten, nämlich SelfHTML und die Feature-Artikel (leider noch nicht die Tips & Tricks ...), sind immer dabei. Auch dies ist eine Performance- und Qualitätsfrage.

Kleine Hilfs-Tabellen die man immer braucht(z.B. die Liste mit den häufig vorkommenden Suchworten) sollten sowieso in den RAM, oder?

Wenn die Tabelle wirklich klein ist, dann wird sie von der Datenbank (oder ersatzweise vom Festplattentreiber des Betriebssystems) ohnehin gecached. Interessant wäre der zusätzliche RAM, um eine _große_ Tabelle zu beschleunigen ... oder einen großen Indexbaum mit relativ zufällig verteilten Zugriffen.

Viele Grüße
      Michael