At 04:37 AM 11/23/2004, ArnoldGamboa.com wrote:

>Correct me if I'm wrong. I think that firebird fills the remaining
>parts of the field with blank spaces.

As Martijn said, char fields are blank filled - that's the
normal thing for that datatype in SQL databases.

What you're seeing (I think) is an artifact of the way Firebird stores
data. Before a record is written to a page in the database, two things
happen to it. First, it is laid out in a buffer, fully expanded. That
means that character fields are padded with spaces to their maximum
length, null fields are assigned zeros or blanks depending on type,
and system alignment rules are applied. That format makes locating
data within a record very simple. Then second, the record is compressed
using a run-length algorithm. All the added blanks and zeros disappear.

>Say I have a varchar(50) field.
>I entered a record with, say, 10 characters.

I don't know now php returns varchars. Their stored format is
two binary bytes of length followed by the value, padded with
blanks to full size. Most languages request varchars as null
terminated strings, so you never see the trailing blanks.

>Questions:
>
>1. If this is the case, does this mean that, if I declare a field of
>50 chars, even if i don't use them all, each record will consume 50 bytes?

No. A varchar(50) consumes 52 bytes uncompressed and 2 + strlen + 1 + 1
bytes on disk. The first 2 is the length. The first 1 is a byte
indicating the number of identical bytes that follow. The second 1 is
byte that contains the repeated value.

>2. Is there a work around so that the other free spaces are not used up?

Yes and it's automatic.


Regards,


Ann