Varbinary - Varchar - BLOB (MySQL))

[Honda]

Hallo,

ich bin am überarbeiten einer Volltextsuche (MySQL).

Fakten:
Ich habe eine Tabelle mit mehreren Varchar(250)-Spalten.
In diesen soll nach belieben gesucht werden können.

Meine Frage:
Es sollen auch griechische und russische Zeichen darin gespeichert werden (künftig möglicherweise auch chinesische)... ist in dem Fall varchar() noch der optimale Datentyp dafür?

Wären hier evtl. Varbinary oder BLOB besser?
Hat jemand Erfahrungen damit?

Danke für Tipps.
Grüsse,
Honda

[wahsaga]

hi,

Es sollen auch griechische und russische Zeichen darin gespeichert werden (künftig möglicherweise auch chinesische)... ist in dem Fall varchar() noch der optimale Datentyp dafür?

Wären hier evtl. Varbinary oder BLOB besser?

Der (Text-)Spaltentyp ist dafür ziemlich egal.

Was eher von Interesse wäre, dürfte der Typ der Kodierung sein.
Wenn du mit mehreren Sprachen, die auch noch ihre eigenen Sonderzeichen haben, arbeiten willst, wäre sicherlich UTF-8 zu empfehlen - sowhl in der DB, als auch bei der Ausgabe und innerhalb der verarbeitenden Scripte.

gruß,
wahsaga

[Honda]

Hallo,

Was eher von Interesse wäre, dürfte der Typ der Kodierung sein.
Wenn du mit mehreren Sprachen, die auch noch ihre eigenen >Sonderzeichen haben, arbeiten willst, wäre sicherlich UTF-8 zu >empfehlen - sowhl in der DB, als auch bei der Ausgabe und innerhalb >der verarbeitenden Scripte.

Die DB ist auf UTF-8 (general) eingestellt,.... die Skripte arbeiten auch mit UTF-8 codierung.

Ich hab neulich nur gehört, dass es beim Suchen (Volltext) von chinesischen Wörtern vorteilhafter ist wenn varbin oder bin benutzt wird.

...Ist aber "bin" nicht generell Case-sensitiv, sodass die Suchergebnisse lateinischer Wörter wiederum case-sensitiv ausgegben würden?

Grüsse,
Honda

[dedlfix]

echo $begrüßung;

Ich hab neulich nur gehört, dass es beim Suchen (Volltext) von chinesischen Wörtern vorteilhafter ist wenn varbin oder bin benutzt wird.

Welche Begründung wurde für dieses Argument geliefert? Und galt es für alle von MySQL untersützten Character Sets, die chinesische Zeichen abbilden können?

...Ist aber "bin" nicht generell Case-sensitiv, sodass die Suchergebnisse lateinischer Wörter wiederum case-sensitiv ausgegben würden?

Ein (VAR)BINARY-Feld interessiert sich überhaupt nicht mehr für die Inhalte und speichert nur Bytes. Vergleiche finden auch nur byteweise statt.

Anders dagegen verhalten sich (VAR)CHAR-Felder mit dem BINARY-Attribut (das in eine Binär-Collation umgeschrieben wird). Hier werden die Werte der Zeichen, die ja auch aus mehreren Bytes bestehen können, verglichen. Und da hier nur Werte verglichen werden, interessiert es nicht, welche Zeichen diesen Werten zugeordnet sind.

Dass keinerlei Groß-/Kleinschreibweise bei beiden Binärfeldarten beachtet wird, ergibt sich einfach aus den Eigenschaften dieses Feldtyps. Eine Aussage binär = case-insensitiv ist zwar nicht falsch aber genauso überflüssig wie: Ein Binärfeld hat keinen Balkon.

echo "$verabschiedung $name";

[Honda]

Hallo,
ich hab nochmal nachgeschlagen:

Welche Begründung wurde für dieses Argument geliefert? Und galt es für alle von MySQL untersützten Character Sets, die chinesische Zeichen abbilden können?

"Wenn Sie chinesische Daten in der so genannten Big5-Kodierung verwenden, sollten Sie alle Zeichenspalten BINARY machen. Das funktioniert, weil die Sortierreihenfolge von Big5-Zeichen auf der Reihenfolge von ASCII-Codes basiert."

aus --> http://dev.mysql.com/doc/refman/4.0/de/case-sensitivity.html

Ich verwende jedoch eine UTF-8 Codierung,... heisst das, dass dieser Ratschlag für mich nicht gilt?

Grüsse,
Honda

[dedlfix]

echo $begrüßung;

Welche Begründung wurde für dieses Argument geliefert? Und galt es für alle von MySQL untersützten Character Sets, die chinesische Zeichen abbilden können?

"Wenn Sie chinesische Daten in der so genannten Big5-Kodierung verwenden, sollten Sie alle Zeichenspalten BINARY machen. Das funktioniert, weil die Sortierreihenfolge von Big5-Zeichen auf der Reihenfolge von ASCII-Codes basiert."

Ah ja ... Beim letzten Satz erschließt sich mir der Sinn nicht. ASCII verwendet Werte von 0 bis 127, Big5 verwendet 2 Byte, das erste im Bereich von 161 bis 254, das zweite von 64 bis 126 und 161 bis 254. Vielleicht ist statt "ASCII-Codes" Byte-Werte gemeint.

aus --> http://dev.mysql.com/doc/refman/4.0/de/case-sensitivity.html

Hmmm, in den englischen Ausgaben des Handbuchs gibt es den Satz nicht (oder nicht mehr).

Ich verwende jedoch eine UTF-8 Codierung,... heisst das, dass dieser Ratschlag für mich nicht gilt?

Ich nehme an, er gilt nicht. Bei meiner Recherche landete ich in der Unihan Database, die auch Mappings zu verschiedenen anderen Codierungen enthält. Am verlinkten Ort gibt es einen Link zu einem gezippten Textfile (5.6 MB), das für alle relevanten Unicode-Werte die Entsprechungen in anderen Kodierungen enthält. Die ersten paar BIG5-relevanten Eintragungen sind:

U+4E00 kBigFive A440
U+4E01 kBigFive A442
U+4E03 kBigFive A443
U+4E07 kBigFive C945
U+4E08 kBigFive A456
U+4E09 kBigFive A454
U+4E0A kBigFive A457
U+4E0B kBigFive A455
U+4E0C kBigFive C946
U+4E0D kBigFive A4A3
U+4E0E kBigFive C94F
U+4E0F kBigFive C94D

Zu sehen sind zum einen Lücken in den Unicode-Werten (für die es wohl keine BIG5-Entsprechung gibt) und zum anderen die bunte Mischung der BIG5-Werte.

echo "$verabschiedung $name";