Re: char oder varchar

Geschrieben von Gernot Ruban on April 05, 2002 um 17:29:

Als Antwort auf char oder varchar geschrieben von Albert Baumann on April 04, 2002 um 11:59:

Hi Albert,

Zur Frage CHAR oder VARCHAR:

Mit der Handhabung der Längenfelder ist ein gewisser Overhead verbunden. Der CPU Overhead kann u.U. jedoch durch Einsparung des I/O Overheads belohnt werden.

In Cobol ist die Handhabung nicht so einfach wie in PL/I. Dies scheint dazu zu verführen den VARCHAR String mit Blanks aufgefüllt zu speichern und das Längenfeld nicht korrekt zu setzen.
In anderen Sprachen kann es allerdings wieder zu Problemen kommen, wenn unterschiedliche lange Strings miteinander verglichen werden (= ist nicht gleich ==). Hier hilft allerdings die TRIM Funktion (per SQL oder Pgm/Script) das Problem zu umgehen.

Ich habe mal von einer Grenze von mindestens 18 Bytes gehört, die eine VARCHAR Column schon haben sollte, damit sich die Einsparung lohnt.

VARCHAR hat bezügl. Logging ein anderes Verhalten als CHAR - wieder mehr Overhead. Deswegen VARCHAR Felder immer hinter alle anderen Columns im CREATE TABLE placieren.

Bei kurzen Columns spricht also alles für CHAR statt für VARCHAR!

Gruß
Gernot

Antworten:

Schreibe eine Antwort

Name:
E-Mail:

Thema:

Kommentar:
: Hi Albert, : Zur Frage CHAR oder VARCHAR: : Mit der Handhabung der Längenfelder ist ein gewisser Overhead verbunden. Der CPU Overhead kann u.U. jedoch durch Einsparung des I/O Overheads belohnt werden. : In Cobol ist die Handhabung nicht so einfach wie in PL/I. Dies scheint dazu zu verführen den VARCHAR String mit Blanks aufgefüllt zu speichern und das Längenfeld nicht korrekt zu setzen. : In anderen Sprachen kann es allerdings wieder zu Problemen kommen, wenn unterschiedliche lange Strings miteinander verglichen werden (= ist nicht gleich ==). Hier hilft allerdings die TRIM Funktion (per SQL oder Pgm/Script) das Problem zu umgehen. : Ich habe mal von einer Grenze von mindestens 18 Bytes gehört, die eine VARCHAR Column schon haben sollte, damit sich die Einsparung lohnt. : VARCHAR hat bezügl. Logging ein anderes Verhalten als CHAR - wieder mehr Overhead. Deswegen VARCHAR Felder immer hinter alle anderen Columns im CREATE TABLE placieren. : Bei kurzen Columns spricht also alles für CHAR statt für VARCHAR! : Gruß : Gernot

Optionale Link URL:
Link Titel:
Optionale Image URL:

[ Antworten ] [ Forum ]