Hi!

+1. Stell' doch mal 'nen Feature-Request ...

wo?
Hab gerade nochmal bei cforum.teamone.de geguckt, da finde ich keinen Hinweis dazu. Dafür aber _sehr_ interessante Featurs vor allem bzgl. des Archivs! Bin schon sehr gespannt, hört sich sehr gut an, soweit man das an den Bezeichnungen sehen kann ;-)

Ich sehe die Benutzung der Suche genauso wie die Benutzung der FAQ: Jeder sollte sie benutzen, nur wenige werden es tatsächlich tun.

Das glaube ich nicht. Wenn die Suche in der Vergangenheit mal nicht ging, da wunderte man sich(ich mich) wer sich darüber alles beschwert hat!

Und auf die tatsächlichen Anwender möchte ich die Funktionalität ausgelegt sehen.

Das finde ich richtig. Ich kann eigentlich auch nur von mir sprechen, es hat schon seine Zeit gedauert bis ich den Selfrauum so einigermaßen überblicken konnte, und selbst heute bin ich immer noch überrascht was es noch so alles gibt.

Wer von sich aus auf die Idee kommt, etwas zu suchen, der sollte _dort_ den Hinweis bekommen, daß es die Tips & Tricks gibt.

Ja, aber das problem sehe ich ein bisschen darin, das man das nicht unbedingt erwartet und mehr oder weniger überliest, oder es nicht wirklich auszunutzen weiß.

Es reicht, wenn man die Augen offen hat, während man im Formular seine Kreuzchen setzt.

Da habe ich erst nach Monaten angefangen was zu verändern...

Vermutlich könnt Ihr es euch nicht erlauben so einen großen Index im RAM zu halten, oder?

Keine Ahnung. Deshalb finde ich Deine Experimente mit mySQL ja so wertvoll. Denn das Prinzip ist ja problemlos auch ohne FULLTEXT verwendbar: Stell Dir einfach vor, Du hättest eine zusätzliche Tabelle mit der Abbildung von Wort auf Posting-ID und würdest über die Worte einen non-unique Index legen ... ich verwendet eine solche Implementierung, und ich habe etwa 20 Millionen Einträge in dieser Tabelle.

Sowas ähnliches habe ich zwischenzeitlich auch gehabt, halt für den Such-String-Sortierer, habe das aber nur kurz versucht, wäre da nicht eine Struktur wie folgt optimal:

Tabelle worte:
  wort_ID
  wort_STRING

Tabelle postings
  wort_ID
  posting_ID

dann könnte man über die wort_ID(INT) joinen, über wort_ID in  Tabelle "worte" einen primary_key und über die wort_STRINGs einen normalen Index, genau so wie über beide Spalten der 2. Tabelle, sollte das nicht schneller sein als eine Tabelle?
Aber ich habe ja schon oben mal nachgefragt wegen eines Binärbaums, habe da auch einiges zu gelesen, wie sich das z.B. in PERL abbilden ließe, aber da weiß ich nicht ob das ganz so schlau ist, denn man müßte jedesmal alle Suchworte in einen Hash laden, und jedesmal den Baum mit den Knoten erstellen. Das wird doch tierisch lange dauern. Kann man eine Baumstruktur nicht fest in irgendeiner Datei speichen, das nur noch der fertige Baum geladen werden und durchsucht werden muß, denn das erstellen des Baums wird vermutlich ähnlich lang dauern wie das erstellen des Fulltext-Index!

Es muß nicht alles im RAM liegen.

Aber _das_ macht den entscheidenen Unterschied! Zumindest in meine Tests, wenn der Index im Cache liegt(die SQL-Abfrage kann in MySQL 3.23 noch gar nicht gecached werden!) wird das sehr schnell, sobald der komplette Index auch der Festplatte nach unschärferen Wörtern durchsucht wird wird er langsam.

Es reicht, wenn pro Zugriff nur eine kleine Menge an Seiten ins RAM eingelagert werden müssen. Und Baumstrukturen sind ein Mittel, dies zu erreichen: Wenn die Komplexität bei 100000 Postings von linear auf logarithmisch sinkt, kannst Du einen Faktor von knapp 1000 an Performance gewinnen. (100000 -> 17 * 7)

bisher konnte ich davon herzlich wenig spüren. viel schneller als die bestehend Archivsuche wurde ich nicht, eher langsamer, es ist irgendwie ein Trade-Off, am Anfang war alles auf den Cache optimiert, hinterher wollte ich gerade neue Anfragen beschleunigen, dadurch wurden aber die "alten" erheblich langsamer :-(

Viele Grüße
Andreas