Hi Andreas,
ja, wie muß ich's denn richtig machen?
das kommt auf Deine Aufgabenstellung an.
halt, ein Forum durchsuchen, nach Name, Thema, Datum, Inhalt des Postings.
modelliere ein Forum-Posting als MYISAM-Tabelle, setze einen FULLTEXT-Index drauf, generiere entsprechende SQL-Queries, führe diese aus, sauge das Ergebnis ab, generiere entsprechende Treffer-Anzeigeseiten.
Die Suchfunktion des Self-Portals ist ein Perl-Skript mit CVS-ähnlichen 'Indexdateien'
Und wie erstellt man so eine Index-Datei?
Durch ein Konverter-Skript, welches aus den Postings die relevanten Informationen heraus parsed (Du willst sicherlich nicht den HTML-Layout-Code Deines Forums durchsuchbar machen?).
Beim Self-Portal geschieht dies durch einen separaten Prozeß, der etwa SelfHTML 8.0 als Eingabe-Dateibaum liest und eine entsprechende Indexdatei ausgibt; beim Forum ist das meines Wissens derzeit ein täglich laufendes Skript mit ähnlicher Funktionalität (deshalb sind archivierte Postings erst nach etwa einem Tag über die Suche auffindbar).
Bei Deinem Forum wäre dies eine Funktion, die innerhalb der Poster-Logik aufzurufen wäre - dort hast Du alle erforderlichen Informationen vorliegen und kannst die Datenstruktur der Suchfunktion entsprechend pflegen.
Ich will ja die Volltextsuche nicht nur in der DB durchführen,
Ich schon - wenn FULLTEXT mir mehrere tausend Zeilen eigenen Quelltext einspart und performanter ist als das, was ich selbst schreiben könnte. Ich habe so eine Suchmaschine mit dem Äquivalent von einer Million "Postings" drin - und die funktioniert prima.
sondern auch in Dateien - da liegen nämlich die Beiträge drin (es handelt sich um ein Forum)
Die Suchfunktion darf (und sollte, in diesem Fall) eine (parallel zu pflegende) redundante Datenstruktur mit denselben Posting-Inhalten wie das Forum verwenden, welche auf ihre spezifischen Bedürfnisse (Performance) optimiert ist.
Ob diese separate Datenstruktur eine Datenbank oder eine CVS-Datei ist, das hängt von den spezifischen Bedürfnissen ab, also was genau Du alles finden können willst und welche der möglichen Such-Anforderungen wie performant erledigt werden müssen. Steigende Ansprüche ziehen steigenden "Investitionsbedarf" nach sich, auch bezüglich der verwendeten Basistechnologien.
In meinem konkreten Fall ist es sogar so, daß ich die gesamte Datenhaltung in der Datenbank vorgenommen habe - mein "Posting-Viewer" liest den Inhalt des Postings aus derselben Tabelle, über deren FULLTEXT-Index die Suchfunktion dieses Posting gefunden hätte.
Dies liegt in meinem Fall daran, daß ich nicht wirklich ein "Forum" betreibe, sondern ein Nachrichtenarchiv - es gibt bei mir kein Äquivalent zur Forumshauptdatei, sondern alle Zugriffe erfolgen zunächst einmal über einen Suchvorgang (selbst die 'Liste der aktuellsten Beiträge' ist bei mir ein Such-Ergebnis - das Tabellen-System ist für diese Anforderung entsprechend getuned). Ich habe auch keine "Threads" - insofern ist meine Aufgabenstellung eine signifikant andere als bei einem normalen Forum, und nicht alle Erkenntnisse sind problemlos übertragbar ...
Viele Grüße
Michael
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
(sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
=> http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.