Bär = Bar in utf8_general_ci

[pekka]

Ich finde jede Menge Info zum Thema aber kein Workaround. Ich habe eine mySQL-Datenbank in utf8_general_ci.
Mache ich nun ein

SELECT * FROM tabelle WHERE name LIKE "%Bar%"

bekomme ich neben "Bar" in den Ergebnissen auch "Bär".
Das Verhalten ist so bekannt und definiert, paßt mir aber nicht.
Weiß jemand einen Weg, dieses Verhalten zu ändern, ohne die Kollation umstellen zu müssen? Am Besten direkt in der Query?

SELECT * FROM tabelle WHERE BINARY name LIKE "%Bar%"

ist leider zuviel des Guten: Damit wird die Abfrage case sensitive, was ich aber vermeiden möchte.

[h3ll]

MySQL :: MySQL 5.0 Reference Manual :: 9.1.6.1 Using COLLATE in SQL Statements

[Slava]

oder weiter mit BINARY, aber vorher upper bzw lower machen

select lower('Bär')=binary(lower( 'Bar'))

[pekka]

COLLATE wär's im Grunde, klappt hier aber nicht auf Anhieb, weil die einzige Collation die ich nutzen kann latin_german2_ci ist - und das verträgt sich nicht mit UTF8.

Lower() geht nicht mit LIKE - außer ich "lower"e das ganze abzufragende Feld, was wiederum performancemäßig nix ist.

Weiß jemand auf Anhieb, was ich wo CONVERTen muß, um die Abfrage in latin_german2_ci zu kriegen und COLLATE nutzen zu können?

[Abraxax]

Lower() geht nicht mit LIKE - außer ich "lower"e das ganze abzufragende Feld, was wiederum performancemäßig nix ist.

Klappt das so?

SELECT * FROM tabelle WHERE LOWER(name) LIKE CONCAT("%", LOWER("Bar"), "%");

Wenn das unter WHERE nicht klappt, evtl. mit HAVING testen ...

[h3ll]

Genau das lowert ja jedes Feld in der Datenbank, was natürlich Performance kostet. Oder was denkst du, was LOWER(name) macht?

[Abraxax]

Ausprobieren ... wie stark die Belastung ist.

DESC SELECT ....

[Slava]

lower macht natürlich genau so viel bremse wie collationsänderung am laufendem.
Was ich mir noch vorstellen kann, dass man erst zwischenergebnis in eine Temporäre-Tabelle abspeichert, um die Suche abzugrenzen und dann in dem zweitem Schritt lover oder replace macht und noch ein mal like anwendet.
In diesem fall wird lover oder replace nicht auf die ganze spalte, sondern auf die vorselectierte Ergebnis wirksam

nicht getestet!
SELECT t1.* from tabelle as t1 inner join (SELECT id, replace(name,'ä','') as neuname FROM tabelle WHERE name LIKE "%Bar%")as Schritt1 on t1.id=Schritt1.id where Schritt1.neuname like "%Bar%";

[wahsaga]

weil die einzige Collation die ich nutzen kann latin_german2_ci ist

Warum?

Collations sind in erster Linie dazu da, anzugeben, wie Vergleiche durchgeführt werden sollen - welche Zeichen man also als gleichwertig angesehen haben möchte.

Du hast jetzt eine gewählt, die a==ä setzt - und wilst aber genau dieses "Feature" gar nicht haben?


Wenn es da aus irgendwelchen ungünstigen Umständen wirklich keine Möglichkeit geben sollte, eine günstigere Collation zu wählen - dann mach halt eine extra Spalte, entweder die schon gleich mit passenderer Collation versehen, oder wo du das Ergebnis von LOWER redundant vorhältst, und nutze diese zum Vergleichen, wenn du dir andernfalls Sorgen um die Performance machst.

[pekka]

Du hast jetzt eine gewählt, die a==ä setzt - und wilst aber genau dieses "Feature" gar nicht haben?

Welche UTF8-Basierende Kollation macht das denn nicht?
Mein Problem ist nicht, daß ich die Kollation gar nicht wechseln kann. Nur zu den Latins will ich nicht mehr.
Das mit der Extra-Spalte ist alternativ aber eine gute Idee.

[wahsaga]

Ausser utf8_bin gibt's wohl keine; aber damit wird's dann wieder cs - dann bleibt ausser LOWERn vorm vergleichen wohl wirklich keine Möglichkeit.

[pekka]

Ich denke, ich werde auf Dauer Extra-Spalten anlegen, die in latin1_german_ci gehalten sind. Bis dahin behelfe ich mir mit lower() oder filtere unerwünschte Ergebnisse im PHP-Code aus. Vielen Dank für die Beiträge!