Fehlertollerante Suche

[medium22]

Hallo,


Ich würde gerne in eine Suche (Suche nach einem Wort) eine gewisse Fehlertolleranz (ggü. dem originalen DB-Inhalt) erlauben / ermöglichen. Es geht hierbei nur um 'Sonderzeichen' (zb. ä, ö, ü, ...).

Die Daten / Worte werden in einer MySQL-Datenbank im HTML-Format gespeichert. Das ü also als ü, usw. Nun soll es dem Suchenden aber möglich sein einen 'Fehler' im Wort (ggü. der DB) zu haben. So soll also beim Suchbegriff "Boese" auch "Böse" gefunden werden - das als Beispiel.

Meine Idee war im ersten Moment, für jedes Sonderzeichen ein Array anzulegen in welchem die versch. Möglichkeiten drin sind. Diese dann wiederum werden abgefragt, sollte ein solches Zeichen im Suchbegriff vorhanden sein - bzw. im Suchbegriff ersetzt, ...
Gibts da irgend eine bestimmte Vorgabe welche man einhalten muss, oder gar etwas fertiges seitens PHP?
Oder habt ihr eine bessere Idee?


Gruss

[wahsaga]

Die Daten / Worte werden in einer MySQL-Datenbank im HTML-Format gespeichert. Das ü also als ü, usw.

Dieses „also“ bedingt nicht die logische Notwendigkeit, nach der es klingen möchte.
Wähle eine geeignete Zeichenkodierung, so dass du keine Entities für solche „Sonderzeichen“ brauchst.

Nun soll es dem Suchenden aber möglich sein einen 'Fehler' im Wort (ggü. der DB) zu haben. So soll also beim Suchbegriff "Boese" auch "Böse" gefunden werden - das als Beispiel.

Das lässt sich dann, wenn du obiges umgesetzt hast, schon allein durch die Wahl einer passenden Collation erreichen.

[medium22]

Hallo,


Ich hole den Thread nochmal hoch weil es im Prinzip um das selbe Grundthema geht - diesmal allerdings um MySQL, also bitte verschieben *g*

Es geht darum, dass die DB 'leichte' Schreibfehler erkennen soll. Ich wurde dann auf SOUNDEX aufmerksam gemacht und versuchte mich sogleich daran - jedoch ohne Ergebnis.

 SELECT name, zusatzinfo, date
FROM liste
WHERE frei =1
AND SOUNDEX(name) = SOUNDEX("%Zleip%")
ORDER BY name
LIMIT 0 , 30

Original wäre "Sleip", die DB sollte aber auch 'Leip', etc. erkennen - soll damit ja eigentlich möglich sein wie man im www so liest. Der Suchbegriff ist unterschiedlich lang, jedoch nie kürzer als 3 Zeichen (soundex benötigt mind 4, ich weiss - aber die 3 Zeichen treffen auf max. 10 Zeilen zu, daher akzeptabel). 'name' ist als varchar(50) definiert - muss es ggf. ein text-feld sein?


Gruss & Danke

[AmicaNoctis]

Hallo,

mal davon abgesehen, dass du soundex falsch benutzt, wird es wohl für die deutsche Sprache wenig gewinnbringend sein, weil die zugrundeliegende Phonetik nur für's Englische implementiert ist. Es gibt aber auch eine deutsche Soundex-Implementation von einer gewissen Dame hier aus dem Forum.

Gruß,

Amica

[medium22]

Was würden wir alle machen wenn wir dich nicht hätten! <luftigkuss schick>

Werde ich mir die Tage mal genauer anschauen - mal schauen ob mein Hoster das überhaupt zulässt. *g*


Danke!

[medium22]

Bin nun doch eher dazu gekommen - so kurz vorm schlafen.

Code eingefügt > Fehlermeldung 'delimiter;', aber die Routinen wurden trotzdem angenommen - sie werden jedenfalls angezeigt. Führe ich nun folgenden Query in phpma aus...

SELECT name, zusatzinfo, date
FROM liste 
WHERE frei =1
AND soundex_de(name) = soundex_de('Zleip')
ORDER BY name
LIMIT 0 , 30

bekomme ich
#1267 - Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_unicode_ci,COERCIBLE) for operation 'regexp' als Fehlermeldung. So ganz werde ich daraus nicht schlau. Habe aber trotzdem mal die Tabelle in der ich Abfrage auf utf8 gesetzt (jede Spalte als auch die Tabelle selbst), am Ergebnis änderte sich aber nichts.

Woran kann das liegen? Vielleicht das mein Hoster irgend etwas davon nicht unterstützt oder doch an der Kollation?

[AmicaNoctis]

Hm, dazu fällt mir grad nicht viel ein, aber ich hab es ausprobiert. Die ganze Tabelle ist bei mir utf8_general_ci, damit auch die Spalte last_name. Folgende Statements habe ich ausprobiert mit der Ausgabe dahinter:

select soundex_de(`last_name`) from `caller` limit 1; --> 882
select soundex_de(convert(`last_name` using latin1)) from `caller` limit 1; --> 882
select soundex_de(convert(`last_name` using binary)) from `caller` limit 1; --> 882
select soundex_de(cast(`last_name` as binary)) from `caller` limit 1; --> 882

Bei mir funktioniert es also mit allem, von binär über ANSI bis zu UTF-8. Meine Version: MySQL 5.1.50

Edit: zeig mir mal deine Ausgabe für folgende Statements:

show function status;
use `SCHEMA`; -- ersetze SCHEMA durch den Wert der Spalte Db aus der vorherigen Abfrage
show create function `soundex_de`;
show create function `strip_non_alpha`;

[medium22]

Seltsame Sache..

- die Datenbank selbst hat MySQL-Zeichensatz: UTF-8 Unicode (utf8)
- die meisten Tabellen (alle bis auf die aus der ich abfrage, die hat utf8_general_ci) haben latin1_swedish_ci als Kollation

Führe ich nun deine Anweisung untern dem Reiter 'SQL' in dieser Tabelle (liste) aus..

show function status;
use `liste`; -- ersetze SCHEMA durch den Wert der Spalte Db aus der vorherigen Abfrage
show create function `soundex_de`;
show create function `strip_non_alpha`;

..., erhalte ich #1044 - Access denied for user 'xxx'@'%' to database 'liste'

Führe ich deine Anweisung unter dem Reiter 'SQL' in der Gesamtübersicht aller Tabellen aus...

show function status;
use `xxx`; -- ersetze SCHEMA durch den Wert der Spalte Db aus der vorherigen Abfrage
show create function `soundex_de`;
show create function `strip_non_alpha`;

..., erhalte ich folgendes:



Die Funktion 'soundex_de' wird also gar nicht ausgegeben bzw. kreiert.

[AmicaNoctis]

Ahja, da haben wir es schon. Der hat due Funktionen als latin1 angelegt. Mach mal die beiden Funktionen wieder weg (drop function), geh mit use in ein Schema, welches utf8 als default charset besitzt, stell sicher, dass der Verbindungszeichensatz auch utf8 ist und führ den Code dann nochmal aus.

[medium22]

Ich konnte ihn auch so direkt bearbeiten/editieren und einfach latin1 durch utf8 ersetzen - hat er/sie gefressen *g*

Wenn ich nun die obige Abfrage ausführe kommt schon mal keine Fehlermeldung mehr, dennoch wird der 'Schreibfehler' (Sleip / Zleip) nicht erkannt. Der Test mit der Suche nach 'tark' (statt 'Dark') bringt allerdings ein Ergebnis - funktioniert also schon. :-)


Wie kann ich das der Routine beibringen? Kenne mich mit solch komplexen Dinge nicht wirklich aus.
Also sozusagen, dass 's' und 'z' gefolgt von egal was (ebenso das davor) ebenfalls ein Ergebnis bringt.

[AmicaNoctis]

Ich weiß nicht, was du meinst.

mysql> select soundex_de('zleip'), soundex_de('sleip');
+---------------------+---------------------+
| soundex_de('zleip') | soundex_de('sleip') |
+---------------------+---------------------+
| 851                 | 851                 |
+---------------------+---------------------+
1 row in set (0.02 sec)

Sicher, dass er es "gefressen" hat? Eventuell ist er trotzdem nicht so, wie er sein sollte. Das könnte zumindest erklären, warum bei dir sleip und zleip nicht denselben Hash bringt.

[medium22]

Ich nehm's zurück - vielleicht sollte ich einfach mal eine Woche am Stück schlafen! Funktioniert natürlich > Bedienungsfehler.