nicht angemeldet
Hallo,
Der einzige Vorteil von Char gegenüber Varchar ist, dass konstante Feldlängen zu einer leichteren Auffindbarkeit eines Datensatzes führen.
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?
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.
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]
Wie wird in MySQL solch ein Fall wirklich behandelt?[2]
Grüße
Klaus
[1] Das Problem hat auch der .NET-DataProvider für/von Oracle. Ein Unique-Constraint auf ein VARCHAR2-Feld in der DB erkennt die Unterschiedlichkeit von 'ABC' und 'ABC ', der selbe Contraint im DataProvider hat mit solchen Dtaensätzen dann aber ein Problem.
[2] Je mehr ich von MySQL so mitbekomme um so weniger mach ich diese Datenbank:-(