Vinzenz Mai: Volltextsuche

Beitrag lesen

Hallo Tobias,

Die dort beschriebene "Komprimierung" ist in meinen Augen unbrauchbar.
Mir scheint der Beitrag aus der Zeit vor MySQL 4.1 zu stammen.

könntest du das etwas näher Erläutern, warum sie in deinen Augen unbrauchbar ist?

hab' ich das nicht schon getan:

  • strip_tags ist eine grobe Wildsau
  • möchtest Du eventuell Attribut-Inhalte erhalten, z.B. von alt-Attributen.
  • stripslashes() auf Datenbankinhalte? Warum? Fast immer ein Fehler.
  • Umwandlung von Nicht-ASCII-Zeichen?
       Nein, nutze die entsprechende Kollation.

vergleiche das mit den fünf Listenpunkten der dortigen Komprimierung:

*  HTML-Tags entfernen (strip_tags())
nein, das will man nicht, siehe meine beiden ersten Punkte.

* Slashe entfernen (stripslashes())

Das will man erst recht nicht. Was sollen irgendwelche Slashes in Datenbankinhalten. Da sollten keine Slashes drin sein, die man nicht ganz speziell haben will.

* Leerzeichen entfernen (trim())
das wird vermutlich wenig schaden, aber auch nicht viel nutzen.

* In Kleinbuchstaben umwandeln (strtolower())
wie wäre es mit einer ci-Kollation (ci wie case insensitive). Also überflüssig, siehe letzte meiner Anmerkungen.

* Sonderzeichen umwandeln und entfernen
Warum in aller Welt das. Nein, natürlich nicht. Es verfälscht die Suchergebnisse. Selbstverständlich will ich diese normalen Zeichen meiner Sprache erhalten, damit ich ganz gezielt nach Wörtern suchen kann, die diese enthalen. Außerdem kann ich eine Kollation verwenden, die z.B. ß und ss als gleich ansieht.

MySQL 4.1 brachte enorme Fortschritte bei Zeichencodierung und Kollation. Deswegen meine Vermutung, dass ein Teil der Prinzipien dieser "Komprimierung" aus der Zeit vor MySQL 4.1 stammt.

Bleibt als einzig nicht besonders schädliche Maßnahme das Trimmen.

Nochmals: wenn die Volltextsuche angemessen konfiguriert ist, will man diese verwenden. Dazu kommt die Ineffizienz der Suche, die je zusätzlichem Suchwort zwei zusätzliche Selfjoins über nicht gerade kleine Tabellen hinzufügt - eine Performancebremse erster Güte. Das Nichtverwenden von Subselects deutet ebenfalls auf die Zeit vor MySQL 4.1 hin.

Statt dieser Selfjoins könnte man die Strategien 2) und 3) dieses Archivbeitrags von mir verwenden. Es bleibt, dass diese Suche *nicht* skaliert.

Freundliche Grüße

Vinzenz