nicht angemeldet
Abfrage in MySQL-DB führt zu falschem Ergebnis
Hallo,
ich möchte in meiner DB-Tabelle ein bestimmtes Feld durchsuchen, in dem der Inhalt einen bestimmten Anfangsbuchstaben hat.
Das funktioniert wie gewünscht, bis auf eine Ausnahme.
Ein Inhalt beginnt mit einem 'Ü'. Wenn ich nach dem Anfangsbuchstaben 'Y' suche, dann bekomme ich als Ergebnis genau den Inhalt mit dem Anfangsbuchstabne 'Ü'.
Die Abfrage sieht folgendermaßen aus:
SELECT
`id`,
`text`
`name`
FROM `meineTabelle`
WHERE `text` LIKE 'Y%'
ORDER BY `text`
Als Ergebis bekomme ich den Datensatz, wo das Feld text den Inhalt Üben enthält.
Woran kann das liegen?
Gruß,
Floater
-
Hallo,
ich möchte in meiner DB-Tabelle ein bestimmtes Feld durchsuchen, in dem der Inhalt einen bestimmten Anfangsbuchstaben hat.
Das funktioniert wie gewünscht, bis auf eine Ausnahme.
Ein Inhalt beginnt mit einem 'Ü'. Wenn ich nach dem Anfangsbuchstaben 'Y' suche, dann bekomme ich als Ergebnis genau den Inhalt mit dem Anfangsbuchstabne 'Ü'.Die Abfrage sieht folgendermaßen aus:
SELECT
id,
text
nameFROM
meineTabelleWHERE
textLIKE 'Y%'ORDER BY
text> > Als Ergebis bekomme ich den Datensatz, wo das Feld `text` den Inhalt Üben enthält. > > Woran kann das liegen? > > Gruß, > Floater Ich denke das liegt an dem LIKE, scheinbar ist Y Like Ü :)-
Hi,
AFAIK
ist Like je nach einstellung der DB fast schon wie soundex ... also versucht ÄHNLICHE sachen zu finden und ü und y klingen sehr ähnlich ... irgendwo gibbet noch ne möglichkeit exactmatch zu machen ...... aber dann funktionieren wieder andere dinge in der mysql netGruß
--------------IT & PR - Fenebris.com
janfeddersen _at_ dunkelnetz _dot_ de
Kredite, Umschuldung, Finanzen-
Moin!
AFAIK
ist Like je nach einstellung der DB fast schon wie soundex ...Aber nicht unerwartet, sondern immer basierend auf der gewählten Kollation der jeweiligen Spalte.
also versucht ÄHNLICHE sachen zu finden und ü und y klingen sehr ähnlich ...
Genau, wie im Handbuch beschrieben, hält die Suche abhängig von der Kollation Buchstaben für äquivalent, die nicht identisch sind.
irgendwo gibbet noch ne möglichkeit exactmatch zu machen ...... aber dann funktionieren wieder andere dinge in der mysql net
Man kann einen Binärvergleich erzwingen. Dann verliert man direkt nur die Möglichkeit, case-insensitiv zu vergleichen, wenn man nicht direkt dagegen arbeitet (also beispielsweise beide Strings vor dem Binärvergleich in lowercase wandelt).
Eine ganze Spalte kann natürlich auch mit einer Binär-Kollation definiert werden - die Auswirkungen sind da sehr gering, außer halt hinsichtlich der Vergleiche und Sortierung, die dann wirklich explizit anhand der Bytecodes der gespeicherten Zeichen erfolgt, und nicht mehr basierend auf der alphabetischen Ordnung einer menschlichen Sprache.
- Sven Rautenberg
-
-
-
Moin!
Ein Inhalt beginnt mit einem 'Ü'. Wenn ich nach dem Anfangsbuchstaben 'Y' suche, dann bekomme ich als Ergebnis genau den Inhalt mit dem Anfangsbuchstabne 'Ü'.
Dann hast du latin1_swedish_ci als Kollation gewählt. In der schwedischen Sprache ist Y = Ü in der Alphabetsortierung.
Um das auf deutsche Verhältnisse zu polen, solltest du latin1_german1_ci oder latin1_german2_ci wählen, je nachdem, ob bei dem Vergleich "Ä" wie "A" behandelt werden soll, oder wie "AE". Case-insensitiv sind die Vergleiche in allen drei Fällen (deshalb "_ci").
Siehe dazu im Detail: http://dev.mysql.com/doc/refman/5.1/en/charset-we-sets.html
Alternativ kannst du natürlich auch auf Unicode umstellen: utf8_general_ci bzw. utf8_unicode_ci. Das hat auch wieder Auswirkungen auf die Sortierung und Identitätsprüfung, siehe http://dev.mysql.com/doc/refman/5.1/en/charset-unicode-sets.html.
- Sven Rautenberg