Stephen Gutknecht wrote:
> I got this information from a misinterpretaton of an answer
> you gave me 1
> year ago :) Sorry I took your "they are equal" anser to mean
> it was a space
> waster and not a saver on fields > 30. I had assumed you
> were saying that
> all VARCHAR's were stored in CHAR, not the other way around.
>
> Just so I'm not getting confused.
>
> VAL1 '01234567890123456789012345678901' (32 chars)
> VAL2 '01234567890123456789012345678901' (32 chars)
> VAL3 '01234567890123456789012345678901' (32 chars)
> VAL4 '012345678901234567890123456789012345678901234' (45 chars)
>
> If I put these four values in a field of VARCHAR(50) it would
> consume the
> same amount of storage space if I had used a VARCHAR(250) field?
Yes,
if this field is NOT one of the first (n-1) fields of the primary
key.
Elke
SAP Labs Berlin
> -----Original Message-----
> From: Zabach, Elke [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, April 14, 2002 10:28 PM
> To: 'Stephen Gutknecht (SAPDB)'; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: Experience on linux/sapdb with VLDB (750 GIG)?
>
>
> Stephen Gutknecht wrote:
>
> > Hi Dominik,
> .....
> > SAPDB also uses CHAR internally for all VARCHAR fields, it
> is possible
> > another system may optimize storage for VARCHAR.
>
> Oops, where did you get this info from?
> VARCHAR is VARCHAR, i.e. Character column with VARIABLE
> length (except for
> the first (n-1) primary keycolumns).
>
> It is just the other way round, that means:
> CHAR (n) with n > 30 will be VARCHAR to avoid storage overhead.
>
> Elke
> SAP Labs Berlin
>
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general
