Bei SELECT keine Unterschiede zwischen Vokalen und ihren Umlaut-Entsprechungen?

Hallo zusammen,

mein eigentliches Problem ist, dass ich bei Abfragen wie

SELECT * FROM tabelle where Orte like "Mü%"

nicht nur Zeilen mit "München", sondern auch mit "Much" geliefert bekomme
(und eben auch umgekehrt), was ich nicht will. Daran ändert sich auch
nichts, wenn ich die Kollation meiner varchar-Spalten von utf8_general_ci
auf utf8_unicode_ci umstelle, was mir nach diesem Text

http://dev.mysql.com/doc/refman/5.1/de/charset-unicode-sets. html#id3007223

auch klar ist. Aber dafür sollte doch nun eigentlich wenigstens mit

SELECT * FROM tabelle where Orte like "Sass%"

nicht nur "Sassnitz", sondern auch "Saßleben" gefunden werden? Tuts aber
nicht.

Oder spielt die Kollation wirklich nur für die Sortierung selbst eine Rolle,
nachdem die "passenden" Zeilen also schon entsprechend der Select-Vorgabe
herausgesucht wurden? Aber warum werden dann auch auf dieser der Sortierung
vorgelagerten Ebene Vokale bereits ihren Umlaut-Entsprechungen
gleichgesetzt? Und wie kann ich das verhindern?

Danke und Grüße,
Frank

Re: Bei SELECT keine Unterschiede zwischen Vokalen und ihren Umlaut-Entsprechungen?

Frank Glück schrieb:
> Hallo zusammen,
>
> mein eigentliches Problem ist, dass ich bei Abfragen wie
>
> SELECT * FROM tabelle where Orte like "Mü%"
>
> nicht nur Zeilen mit "München", sondern auch mit "Much" geliefert bekomme
> (und eben auch umgekehrt), was ich nicht will. Daran ändert sich auch
> nichts, wenn ich die Kollation meiner varchar-Spalten von utf8_general_ci
> auf utf8_unicode_ci umstelle, was mir nach diesem Text
>
> http://dev.mysql.com/doc/refman/5.1/de/charset-unicode-sets. html#id3007223
>
> auch klar ist. Aber dafür sollte doch nun eigentlich wenigstens mit
>
> SELECT * FROM tabelle where Orte like "Sass%"
>
> nicht nur "Sassnitz", sondern auch "Saßleben" gefunden werden? Tuts aber
> nicht.
>

Weil das so in der Dokumentation steht (dann solltest Du einen Bugreport
schreiben) oder weil Du das so erwartest?

> Oder spielt die Kollation wirklich nur für die Sortierung selbst eine Rolle,
> nachdem die "passenden" Zeilen also schon entsprechend der Select-Vorgabe
> herausgesucht wurden?

Collation = Sortierung, ja.

> Aber warum werden dann auch auf dieser der Sortierung
> vorgelagerten Ebene Vokale bereits ihren Umlaut-Entsprechungen
> gleichgesetzt? Und wie kann ich das verhindern?
>

Vielleicht, indem Du die Collation auf latin1_german1_ci stellst? Ich
habe das jetzt nicht ausprobiert, aber IIRC findet die Suche in meinen
Tabellen (die german und *nicht* unicode benutzen) immer nur die Vokale
oder die Umlaute.

Re: Bei SELECT keine Unterschiede zwischen Vokalen und ihren Umlaut-Entsprechungen?

"Christian Kirsch" schrieb
> Frank Glück schrieb:
>> Hallo zusammen,
>>
>> mein eigentliches Problem ist, dass ich bei Abfragen wie
>>
>> SELECT * FROM tabelle where Orte like "Mü%"
>>
>> nicht nur Zeilen mit "München", sondern auch mit "Much" geliefert bekomme
>> (und eben auch umgekehrt), was ich nicht will. Daran ändert sich auch
>> nichts, wenn ich die Kollation meiner varchar-Spalten von utf8_general_ci
>> auf utf8_unicode_ci umstelle, was mir nach diesem Text
>>
>> http://dev.mysql.com/doc/refman/5.1/de/charset-unicode-sets. html#id3007223
>>
>> auch klar ist. Aber dafür sollte doch nun eigentlich wenigstens mit
>>
>> SELECT * FROM tabelle where Orte like "Sass%"
>>
>> nicht nur "Sassnitz", sondern auch "Saßleben" gefunden werden? Tuts aber
>> nicht.
>>
>
> Weil das so in der Dokumentation steht (dann solltest Du einen Bugreport
> schreiben) oder weil Du das so erwartest?

Beides, siehe unter obigem Link. Sollte ich da wirklich als erster diesen
Bug (wenn es denn einer ist) gefunden haben? Kann ich eigentlich nicht
glauben ... Wie und wo bekomme ich das denn raus?

>> Oder spielt die Kollation wirklich nur für die Sortierung selbst eine
>> Rolle,
>> nachdem die "passenden" Zeilen also schon entsprechend der Select-Vorgabe
>> herausgesucht wurden?
>
> Collation = Sortierung, ja.

Naja, nach meinen Tests muss ich sagen, es spielt eben sehr wohl schon bei
der Selektion selbst eine Rolle, sonst würden verschiedene Kollationen ja
nicht zu verschiedenen Ergebnismengen führen ...

>> Aber warum werden dann auch auf dieser der Sortierung
>> vorgelagerten Ebene Vokale bereits ihren Umlaut-Entsprechungen
>> gleichgesetzt? Und wie kann ich das verhindern?
>>
>
> Vielleicht, indem Du die Collation auf latin1_german1_ci stellst? Ich
> habe das jetzt nicht ausprobiert, aber IIRC findet die Suche in meinen
> Tabellen (die german und *nicht* unicode benutzen) immer nur die Vokale
> oder die Umlaute.

Merkwürdig, bei mir klappt das nur mit latin1_german2_ci. Bei
latin1_german1_ci werden auch wieder sowohl Vokale als auch Umlaute
gefunden. Wie kann das nun wieder sein? Könnte mir ja egal sein, wenn ich
auch mit latin1_german2 zufrieden wäre. Aber da hier eben auch wieder "ae"
!= "ä", "oe" != "ö", "ue" != "ü" und "ss" != "ß" sind, ist das auch nicht
gerade optimal. Aber alles kann man wohl nicht haben ...(?)

Re: Bei SELECT keine Unterschiede zwischen Vokalen und ihren Umlaut-Entsprechungen?

"Frank Glück" wrote:
>
> mein eigentliches Problem ist, dass ich bei Abfragen wie
>
> SELECT * FROM tabelle where Orte like "Mü%"
>
> nicht nur Zeilen mit "München", sondern auch mit "Much" geliefert bekomme
> (und eben auch umgekehrt), was ich nicht will. Daran ändert sich auch
> nichts, wenn ich die Kollation meiner varchar-Spalten von utf8_general_ci
> auf utf8_unicode_ci umstelle, was mir nach diesem Text
>
> http://dev.mysql.com/doc/refman/5.1/de/charset-unicode-sets. html#id3007223
>
> auch klar ist. Aber dafür sollte doch nun eigentlich wenigstens mit
>
> SELECT * FROM tabelle where Orte like "Sass%"
>
> nicht nur "Sassnitz", sondern auch "Saßleben" gefunden werden? Tuts aber
> nicht.

Korrekt. Wegen einer blödsinnigen Formulierung im SQL-Standard [1]
(oder vielleicht nur einer blödsinnigen Auslegung einer Formulierung
im SQL-Standard) verwenden die Operatoren = und LIKE die Collations
leicht unterschiedlich. Während = alle Regeln einer Collation ver-
wendet, werden bei LIKE keine Regeln verwendet, die die Anzahl der
Zeichen verändern.

Beispiel:

mysql> select 'bär' = 'bar' collate utf8_unicode_ci;
+---+
| 1 |
+---+
mysql> select 'bär' like 'bar' collate utf8_unicode_ci;
+---+
| 1 |
+---+

aber

mysql> select 'fußball' = 'fussball' collate utf8_unicode_ci;
+---+
| 1 |
+---+
mysql> select 'fußball' like 'fussball' collate utf8_unicode_ci;
+---+
| 0 |
+---+


[1] http://dev.mysql.com/doc/refman/5.0/en/string-comparison-fun ctions.html
"Per the SQL standard, LIKE performs matching on a per-character basis,
thus it can produce results different from the = comparison operator:"


XL

Re: Bei SELECT keine Unterschiede zwischen Vokalen und ihren Umlaut-Entsprechungen?

"Axel Schwenke" schrieb
> "Frank Glück" wrote:
[...]
>> auch klar ist. Aber dafür sollte doch nun eigentlich wenigstens mit
>>
>> SELECT * FROM tabelle where Orte like "Sass%"
>>
>> nicht nur "Sassnitz", sondern auch "Saßleben" gefunden werden? Tuts aber
>> nicht.
>
> Korrekt. Wegen einer blödsinnigen Formulierung im SQL-Standard [1]
> (oder vielleicht nur einer blödsinnigen Auslegung einer Formulierung
> im SQL-Standard) verwenden die Operatoren = und LIKE die Collations
> leicht unterschiedlich. Während = alle Regeln einer Collation ver-
> wendet, werden bei LIKE keine Regeln verwendet, die die Anzahl der
> Zeichen verändern.
>
> Beispiel:
>
> mysql> select 'bär' = 'bar' collate utf8_unicode_ci;
> +---+
> | 1 |
> +---+
> mysql> select 'bär' like 'bar' collate utf8_unicode_ci;
> +---+
> | 1 |
> +---+
>
> aber
>
> mysql> select 'fußball' = 'fussball' collate utf8_unicode_ci;
> +---+
> | 1 |
> +---+
> mysql> select 'fußball' like 'fussball' collate utf8_unicode_ci;
> +---+
> | 0 |
> +---+

Verstehe, interessantes Detail das ... Aber wozu sieht die Collation (=
"Textvergleich") dann überhaupt solche eigentlich nützlichen Feinheiten vor,
wenn Sie durch Restriktionen des Textvergleichs-Operators LIKE dann doch
wieder ausgehebelt werden? Oder gibt es andere Möglichkeiten für trunkierte
Abfragen als mit LIKE? Mit = ist sowas ja nun mal leider gerade nicht
möglich ... :-(

Re: Bei SELECT keine Unterschiede zwischen Vokalen und ihren Umlaut-Entsprechungen?

"Frank Glück" wrote:
> "Axel Schwenke" schrieb
>>
>> Wegen einer blödsinnigen Formulierung im SQL-Standard [1]
>> (oder vielleicht nur einer blödsinnigen Auslegung einer Formulierung
>> im SQL-Standard) verwenden die Operatoren = und LIKE die Collations
>> leicht unterschiedlich. Während = alle Regeln einer Collation ver-
>> wendet, werden bei LIKE keine Regeln verwendet, die die Anzahl der
>> Zeichen verändern.

> Verstehe, interessantes Detail das ... Aber wozu sieht die Collation (=
> "Textvergleich") dann überhaupt solche eigentlich nützlichen Feinheiten vor,
> wenn Sie durch Restriktionen des Textvergleichs-Operators LIKE dann doch
> wieder ausgehebelt werden?

Weil so nur LIKE kaputt ist, und = nicht?

*Ich* hätte ja an dieser Stelle gesagt "Scheiß auf den Standard. Wir
machen es lieber richtig."

BTW, ich habe anläßlich dieser Frage mal den Draft zu ISO 9075 über-
flogen. Da habe ich obige Formulierung nicht gefunden. Dafür folgendes
grandiose Statement:

"It is implementation-defined which collations can be used as
collations for the ."

> Oder gibt es andere Möglichkeiten für trunkierte
> Abfragen als mit LIKE? Mit = ist sowas ja nun mal leider gerade nicht
> möglich ... :-(

FULLTEXT Indexe existieren. Und im Zweifelsfall will man sowieso eine
richtige Suchmaschine benutzen. LIKE '%$foo%' ist Volltextsuche für Arme.


XL

Re: Bei SELECT keine Unterschiede zwischen Vokalen und ihren Umlaut-Entsprechungen?

"Axel Schwenke" schrieb
> "Frank Glück" wrote:
>> "Axel Schwenke" schrieb
>
> BTW, ich habe anläßlich dieser Frage mal den Draft zu ISO 9075 über-
> flogen. Da habe ich obige Formulierung nicht gefunden. Dafür folgendes
> grandiose Statement:
>
> "It is implementation-defined which collations can be used as
> collations for the ."

Ähm ... achso. ;-)

>> Oder gibt es andere Möglichkeiten für trunkierte
>> Abfragen als mit LIKE? Mit = ist sowas ja nun mal leider gerade nicht
>> möglich ... :-(
>
> FULLTEXT Indexe existieren.

Du meinst sämtliche vorkommenden Begriffe in Dateien vorhalten?
Naja, ist auch nicht wirklich für alles geeignet. Gerade bei
Ajax-Anwendungen kommts ja doch entscheidend auf ein schnelles schlankes
Feedback an.

> Und im Zweifelsfall will man sowieso eine
> richtige Suchmaschine benutzen.

Will man? Ich dachte bisher eigentlich, dass man mit einem gut durchdachten
DB-System mindestens genauso gut bedient wäre?

> LIKE '%$foo%' ist Volltextsuche für Arme.

Warum? Geht das mit Index-Dateien wirklich performanter?

Re: Bei SELECT keine Unterschiede zwischen Vokalen und ihren Umlaut-Entsprechungen?

Frank Glück meinte:

> "Axel Schwenke" schrieb
>> FULLTEXT Indexe existieren.
>
> Du meinst sämtliche vorkommenden Begriffe in Dateien vorhalten?

Nein. Einen Fulltext-Index auf die entsprechende Spalte einrichten.
Funktioniert bislang nur mit MyISAM Tabellen.

> Warum? Geht das mit Index-Dateien wirklich performanter?

s.o.

Gregor


--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: Bei SELECT keine Unterschiede zwischen Vokalen und ihren Umlaut-Entsprechungen?

"Frank Glück" wrote:
> "Axel Schwenke" schrieb
>>
>> FULLTEXT Indexe existieren.
>
> Du meinst sämtliche vorkommenden Begriffe in Dateien vorhalten?

Ich meine: http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html

>> Und im Zweifelsfall will man sowieso eine
>> richtige Suchmaschine benutzen.
>
> Will man? Ich dachte bisher eigentlich, dass man mit einem gut durchdachten
> DB-System mindestens genauso gut bedient wäre?

Nicht wenn man eine Volltextsuche braucht. Queries mit LIKE '%$foo%'
sind ein deutliches Indiz, daß man die braucht.

Ein Hammer ist auch ein praktisches Werkzeug. Und man kann notfalls
auch Schrauben damit irgendwo rein kloppen. Das bedeutet aber nicht,
daß es keine geeigneteren Werkzeuge dafür gibt.

z.B. http://www.sphinxsearch.com/


XL

Re: Bei SELECT keine Unterschiede zwischen Vokalen und ihren Umlaut-Entsprechungen?

In article ,
Axel Schwenke writes:

> FULLTEXT Indexe existieren. Und im Zweifelsfall will man sowieso eine
> richtige Suchmaschine benutzen. LIKE '%$foo%' ist Volltextsuche für Arme.

.... und eine Einladung für einen SQL-Injection-Angriff, aber das ist
ein anderes Thema.

Re: Bei SELECT keine Unterschiede zwischen Vokalen und ihren Umlaut-Entsprechungen?

"Axel Schwenke" schrieb
> "Frank Glück" wrote:
>> "Axel Schwenke" schrieb
>>>
>>> FULLTEXT Indexe existieren.
>>
>> Du meinst sämtliche vorkommenden Begriffe in Dateien vorhalten?
>
> Ich meine: http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html

Ah, ok, danke - soweit war ich bei mySQL noch nicht vorgedrungen ...;-)
Aber wenn ich das richtig verstehe, macht das ja wahrscheinlich auch nur
Sinn, wenn die zu durchsuchenden Datenfelder auch wirklich Volltext, also
schon etwas mehr als nur ein bis zwei Wörter enthalten, weil sonst die
direkte Suche in diesen Feldern wohl genauso schnell sein dürfte. Oder
funktioniert das mit den Indexen technisch trotzdem auf noch überlegenere
Weise? In meiner Tabelle sind ja nur Felder mit einerseits Ortsnamen und
andererseits Postleitzahlen zu durchsuchen ...(?)

>
>>> Und im Zweifelsfall will man sowieso eine
>>> richtige Suchmaschine benutzen.
>>
>> Will man? Ich dachte bisher eigentlich, dass man mit einem gut
>> durchdachten
>> DB-System mindestens genauso gut bedient wäre?
>
> Nicht wenn man eine Volltextsuche braucht. Queries mit LIKE '%$foo%'
> sind ein deutliches Indiz, daß man die braucht.
>
> Ein Hammer ist auch ein praktisches Werkzeug. Und man kann notfalls
> auch Schrauben damit irgendwo rein kloppen. Das bedeutet aber nicht,
> daß es keine geeigneteren Werkzeuge dafür gibt.

Schöner Vergleich ...;-)

Re: Bei SELECT keine Unterschiede zwischen Vokalen und ihren Umlaut-Entsprechungen?

"Harald Fuchs" schrieb im Newsbeitrag
news:pu8wz6xma0.fsf@srv.protecting.net...
> In article ,
> Axel Schwenke writes:
>
>> FULLTEXT Indexe existieren. Und im Zweifelsfall will man sowieso eine
>> richtige Suchmaschine benutzen. LIKE '%$foo%' ist Volltextsuche für Arme.
>
> ... und eine Einladung für einen SQL-Injection-Angriff, aber das ist
> ein anderes Thema.

.... hmm, inwiefern sollte man sich nicht auch dagegen mit den üblichen
Methoden (http://de.wikipedia.org/wiki/SQL-Injection) absichern können?

Re: Bei SELECT keine Unterschiede zwischen Vokalen und ihren Umlaut-Entsprechungen?

In article <678dhhF2mecvbU1@mid.individual.net>,
"Frank Glück" writes:

> "Harald Fuchs" schrieb im Newsbeitrag
> news:pu8wz6xma0.fsf@srv.protecting.net...
>> In article ,
>> Axel Schwenke writes:
>>
>>> FULLTEXT Indexe existieren. Und im Zweifelsfall will man sowieso eine
>>> richtige Suchmaschine benutzen. LIKE '%$foo%' ist Volltextsuche für Arme.
>>
>> ... und eine Einladung für einen SQL-Injection-Angriff, aber das ist
>> ein anderes Thema.

> ... hmm, inwiefern sollte man sich nicht auch dagegen mit den üblichen
> Methoden (http://de.wikipedia.org/wiki/SQL-Injection) absichern können?

Sicher kann man sowas wie "$foo = escape($foo)" davorschreiben, nur
wird das oft vergessen. Deswegen habe ich mir folgendes Idiom angewöhnt:

$sth = $dbh->prepare(q{
SELECT col
FROM tbl
WHERE col LIKE concat('%', ?, '%')
});
$sth->execute($foo);

Ist zwar Perl, aber vermutlich gibt es etwas derartiges auch in der
Skriptsprache Deiner Wahl.