Re: Char versus VarChar(2)

Hi,
Not overhead of such in the sense of using the string, but overhead when storing the string yes. The VAR in VARCHAR stands for variance. The string varries in size and that includes the storage. It also includes an extra word (double byte) to store the length of the string.

If your string varries in size in the table, the VARCHAR is the fastes thing you can choose. If however, you have a social security number, it doesn't vary in size ... and thus you can save a few bytes, AND the fixed size of the char will not give fragmentation in the table. That last issue is also true if you have little sympathy for linked bloks and fragmented dataspace, and diskspace is not an issue (is it now a days ?), then you can choose to have a character field defined as char, thus fixing the size, but even if the user updates the value from a length of 5 to 8, it doesn't mean a reallocation of space in the block. It just writes over the exiting record.

You need A LOT of transactions before you feel an effect as that. If you are only storing 5000 records, don't mess around with it and choose VARCHAR. Are we talking lots of updates and milions of records, then it has a meaning and a significant priority.

Bill Buchan wrote:
>
> Is there a specific overhead associated with varchar or varchar2 which would
> mean that using char instead would be more efficient for short strings? ie.
> Are things like varchar2(3) or varchar2(5) sensible/preferable to char(3) or
> char(5)?
>
> Thanks,
>
> - Bill.
 

-- 

Peter H. Larsen, Oracle and Applications specialist
Dynamic Resources Inc, Alexandria
Phone: 703-914-9800  #103
Fax: 703-914-9804
Email: plarsen_at_dc.dynares.com
(please remove the nospam from the header when replying to this email)

The above views are my own and does not reflect the views of my
employer.