Sven Rautenberg: Implizite Umwandlung von CHAR in VARCHAR

Beitrag lesen

Moin!

Ist es aber an sich nicht so, dass CHAR immer Zeichenketten mit einer konstanten Länge ablegt und dabei gegebenenfalls mit Leerzeichen auffüllt, falls die eingefügte Zeichenkette kürzer als die vorgegebene Feldlänge ist?

So ist es.

Wenn nun aber, so wie es MySQL macht, CHAR-Datentypen in VARCHAR umgewandelt wird, dann müsste es auch eine Strategie geben, wie man Abfragen wie

select what, ever from table_x
where char6field = 'ABC   '

korrekt ausführen kann. Imho müsste also ein implizites TRIM (oder so ähnlich) ausgeführt werden, da ja die normalerweise aufgefüllten Leerzeichen im Feld fehlen.

Das Handbuch sagt dazu (http://dev.mysql.com/doc/refman/4.1/en/char.html):
"When CHAR values are stored, they are right-padded with spaces to the specified length. When CHAR values are retrieved, trailing spaces are removed."

"VARCHAR values are not padded when they are stored. Trailing spaces in MySQL version up to and including 4.1 are removed from values when stored in a VARCHAR column; this also means that the spaces are absent from retrieved values."

"If you need a data type for which trailing spaces are not removed, consider using a BLOB or TEXT type."

TINYTEXT kann max. 255 Zeichen aufnehmen, TEXT 65534 Zeichen.

Und dann würde es auch passieren, dass man keine zwei Datensätze unterscheiden kann, die sich in einem VARCHAR-Datenfeld nur durch ein abschliessendes Leerzeichen unterscheiden.[1]

Das ist offensichtlich so.

[2] Je mehr ich von MySQL so mitbekomme um so weniger mach ich diese Datenbank:-(

Für Version 5.1 gilt:
"When CHAR values are stored, they are right-padded with spaces to the specified length. When CHAR values are retrieved, trailing spaces are removed."

"VARCHAR values are not padded when they are stored. Trailing spaces are retained when values are stored and retrieved, in conformance with standard SQL."

- Sven Rautenberg

--
My sssignature, my preciousssss!