MySQL Volltextindex mit HTML Seiten
0 
dedlfix
MySQL Volltextindex mit HTML Seiten
Hallo,
Frage 1:
Ich möchte einen MySQL Volltextindex über Produktbeschreibungen anlegen. Diese sind jedoch in HTML formuliert. Ich finde leider keinen Hinweis, wie MySQL mit HTML Tags beim indizieren umgeht. Gibt es dazu eine verlässliche Aussage? Vor allem mit HTML codierten Umlauten und Sonderzeichen?
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?
Frage 2:
Ich würde gerne auch ähnlich klingende Treffer finden. In der MySQL Hilfe steht (Zitat): "Für jeden Datensatz in der Tabelle gibt MATCH() einen Relevanzwert zurück, d. h. eine Maßangabe für die Ähnlichkeit zwischen dem Such-String und dem Text in den in MATCH() aufgelisteten Spalten dieses Datensatzes."
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...?
Donald
-
echo $begrüßung;
Ich möchte einen MySQL Volltextindex über Produktbeschreibungen anlegen. Diese sind jedoch in HTML formuliert. Ich finde leider keinen Hinweis, wie MySQL mit HTML Tags beim indizieren umgeht. Gibt es dazu eine verlässliche Aussage? Vor allem mit HTML codierten Umlauten und Sonderzeichen?
Grundsätzlich sind Dinge, die nicht explizit zugesichert werden, nicht vorhanden. Wenn im Handbuch nichts von einem HTML-Auswerten geschrieben steht, ist auch keins vorhanden. Man müsste das ja auch schaltbar machen, denn manch einer will es vielleicht, andere nicht. Und warum sollte ausgerechnet HTML berücksichtigt werden und $sprache nicht?
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?
In ASCII würde ich den Text nicht konvertieren, denn dabei gehen diverse Sonderzeichen verloren. UTF-8 hielte ich für angebrachter.
Ich würde gerne auch ähnlich klingende Treffer finden. In der MySQL Hilfe steht (Zitat): "Für jeden Datensatz in der Tabelle gibt MATCH() einen Relevanzwert zurück, d. h. eine Maßangabe für die Ähnlichkeit zwischen dem Such-String und dem Text in den in MATCH() aufgelisteten Spalten dieses Datensatzes."
Schöner wäre es gewesen, wenn du das Zitat verlinkt hättest, dann müsste man es nicht zu Fuß suchen gehen.
Dieser Satz steht so nicht (mehr) in der englischen Originalfassung. Dort findet sich an anderer (noch nicht übersetzter) Stelle:
Relevance is computed based on the number of words in the row, the number of unique words in that row, the total number of words in the collection, and the number of documents (rows) that contain a particular word.
Das ist also eine statistische Berechnung und keine nach Ähnlichkeiten.
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.
Oder wie...?
Probier es aus. Nur so sammelt man nicht nur Wissen sondern Erfahrung.
echo "$verabschiedung $name";
-
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
-