nicht angemeldet
Hallo,
Danke erstmal für deine Antwort.
Oder muss ich den Text selbst in ASCII konvertieren, von Tags befreien und den parallel in einem Feld speichern um darauf dann den Index aufzubauen?
Angenommen es würde HTML ausgewertet werde, wie stellst du dir eine Arbeitsweise vor? Soll MySQL jedes Mal bei jeder Suche den Parsevorgang starten? Oder soll es eine verdeckte Schattendatenhaltung haben, in der die HTML-bereinigten Texte stehen? Oder vielleicht zwei Indexe, einen mit und einen ohne HTML?
Ja, ich hatte damit gemeint, dass ich beim abspeichern in PHP den Text in reines UTF-8 wandle und in eine zusätzliche Spalte Fülle. Diese wird dann den Index erhalten. Offensichtlich hat MySQL also keine HTML Technologie für die Volltextsuche?
In ASCII würde ich den Text nicht konvertieren, denn dabei gehen diverse Sonderzeichen verloren. UTF-8 hielte ich für angebrachter.
Ja, das macht sehr viel Sinn.
Das ist also eine statistische Berechnung und keine nach Ähnlichkeiten.
Mist.
Finde ich also bei einer Suche nach "Meier" auch Treffer für "Maier" und "Mayer"? Wenn nicht, kann ich das mit Soundex aufbohren? Eine zweite Spalte, in der von mir alle Wörter in Soundex konvertiert wurden und die ich dann ebenfalls mit einem Volltextindex versehe? Oder wie...?
Wenn dir zusagt, dass Soundex gemäß englischer Ausspracheregeln arbeitet, kannst du das verwenden.
Das bedeutet ich habe drei Spalten:
- ProdDescHTML ohne Volltextindex
- ProdDescText mit Volltextindex
- ProdDescSoundEX mit Volltextindex
Nachteil ist, dass ich die Daten redundant dreimal speichern muss. Aber dann könnte ich mit MATCH('Suchbegriff') in ProdDescText einmal nach dem korrekten Wort suchen und, falls unscharfe Suche gewünscht ist, nochmal mit MATCH(Soundex('Suchbegriff')) nach dem Soundex suchen. Statt dem MySQL Soundex sollte ich allerdings was besseres verwenden. Da gibt es ja viel Infos im Netz...
Naja, aber dreifache Datenhaltung desswegen ist schon nervig. Da muss ich noch drüber nachdenken...
Donald