Bookmarks

Yahoo Gmail Google Facebook Delicious Twitter Reddit Stumpleupon Myspace Digg

Search queries

bind-address mysql multiple, sanibleone xxxx, ftp://192.168.100.100/, www.xxxcon, which comes first ob_start or session, wwwxxx/58/2010, xxxxdup, xxxxdup, mailx informatii, should producers of software-based services, such as atms, be held liable for economic injuries suffered when their systems fail?

Links

XODOX
Impressum

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

Posted on 2008-04-19 14:22:04 by FrankImGlueck

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

Report this message

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

Posted on 2008-04-19 17:59:27 by Christian Kirsch

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.

Report this message

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

Posted on 2008-04-19 20:26:57 by FrankImGlueck

"Christian Kirsch" <ck@bru6.de> 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 ...(?)

Report this message

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

Posted on 2008-04-20 14:36:55 by Axel Schwenke

"Frank Glück" <FrankImGlueck@gmx.de> 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

Report this message

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

Posted on 2008-04-21 22:24:04 by FrankImGlueck

"Axel Schwenke" <axel.schwenke@gmx.de> schrieb
> "Frank Glück" <FrankImGlueck@gmx.de> 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 ... :-(

Report this message

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

Posted on 2008-04-22 01:02:10 by Axel Schwenke

"Frank Glück" <FrankImGlueck@gmx.de> wrote:
> "Axel Schwenke" <axel.schwenke@gmx.de> 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." <schulterzuck>

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 <like predicate>."

> 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

Report this message

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

Posted on 2008-04-22 01:32:57 by FrankImGlueck

"Axel Schwenke" <axel.schwenke@gmx.de> schrieb
> "Frank Glück" <FrankImGlueck@gmx.de> wrote:
>> "Axel Schwenke" <axel.schwenke@gmx.de> 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 <like predicate>."

Ãä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?

Report this message

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

Posted on 2008-04-22 09:04:48 by Gregor Kofler

Frank Glück meinte:

> "Axel Schwenke" <axel.schwenke@gmx.de> 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

Report this message

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

Posted on 2008-04-22 11:07:10 by Axel Schwenke

"Frank Glück" <FrankImGlueck@gmx.de> wrote:
> "Axel Schwenke" <axel.schwenke@gmx.de> 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

Report this message

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

Posted on 2008-04-22 11:37:59 by Harald Fuchs

In article <i0jvd5-6r5.ln1@xl.homelinux.org>,
Axel Schwenke <axel.schwenke@gmx.de> 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.

Report this message

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

Posted on 2008-04-23 11:18:08 by FrankImGlueck

"Axel Schwenke" <axel.schwenke@gmx.de> schrieb
> "Frank Glück" <FrankImGlueck@gmx.de> wrote:
>> "Axel Schwenke" <axel.schwenke@gmx.de> 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 ...;-)

Report this message

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

Posted on 2008-04-23 11:23:59 by FrankImGlueck

"Harald Fuchs" <hari.fuchs@googlemail.com> schrieb im Newsbeitrag
news:pu8wz6xma0.fsf@srv.protecting.net...
> In article <i0jvd5-6r5.ln1@xl.homelinux.org>,
> Axel Schwenke <axel.schwenke@gmx.de> 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?

Report this message

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

Posted on 2008-04-23 13:26:17 by Harald Fuchs

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

> "Harald Fuchs" <hari.fuchs@googlemail.com> schrieb im Newsbeitrag
> news:pu8wz6xma0.fsf@srv.protecting.net...
>> In article <i0jvd5-6r5.ln1@xl.homelinux.org>,
>> Axel Schwenke <axel.schwenke@gmx.de> 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.

Report this message