On the use of VARCHAR2 vs. CHAR

Question

I'm posting an e-mail thread that has been moving around in my organization, whith guidance from an Oracle representative.
The basic issue concerns the use of CHAR vs. VARCHAR2 when defining a table in Oracle.
I would like to get some comments from the community at large.
1. Business semantics should be represented in every aspect of a database, application, and design as far as I am concerned. Noteably, if the business rule at a corporate entity is clearly stated that when using Oracle the use of CHAR should be limited to those attribute implementations which have the following characteristics; a) The attribute may not be null, b) The attribute must have a character in each of the declared positions.
2. When the Visual Basic application began writing data to the CHAR columns in your application someone should have had a discussion with the developer to find out why this was happening. If the business semantics changed then the logical implemention of the business semantics should have changed as well. That the two were disconnected is not a problem with the CHAR type, it is a problem with the designer or the developer. The bottom line on this instance is that the column should have been defined as a VARCHAR2 data type since the business semantics no longer complied with the criteria set forth in the previous paragraph.
3. I think Oracle trys to load as much of the data from a table or index into shared memory, in this case the database block buffers, as it can in order to facilitate query operations. If Oracle has enough memory and can load a table or index into memory, it will do so. At the same time the database engine will move previously cached data out of memory to accommodate the new requirement.
-----Original Message-----
Thank you for the detail information on CHAR and VARCHAR2. It got me thinking with a DBA hat. I worked as a DBA before and I did use the CHAR type and I will share my experience/thought on CHAR.
I don't like to use the char type like Tom has advised because Oracle does not check to see if the value being inserted fills up the column or not which can lead to a problem. And there is no performance gain or save space in Oracle.
I worked as a DBA before, I used char type on the "must fill/always filled" column (pre DMDC). The application was written in VB with Oracle back end. At some point, VB started inserting values that are short of the column width and created a minor problem (it was supposed to be filled column). The problem was quickly identified and fixed, but it caused an issue.
I realize that I don’t want to define it as a "must fill/always filled" column if you can't enforce it by simply defining the char data type on a table and prevent possible issue in the future.
For a manager, in order to use the char properly, you have to hire client developers with Oracle experience or provide a basic Oracle training in order to avoid the problem I mentioned above in order to use the char type correctly.
I think you, Tom and I are saying the same thing really. Only difference is that Tom and I can not think of a good reason why anyone would like to indicate the business semantics using column type on the database, when it can lead to more work/issues.
In regards to wasted 25 million byes, why would Oracle load the table with 25 million rows? Shouldn't it use an index? Don't you have a serious problem if Oracle is loading table with the 25 million rows?
Just my two cents... : )
-----Original Message-----
May I beg to differ?
CHAR plays a vital role in the intuitive interpretation of a database schema. If designed correctly, the use of CHAR tells anyone who is in the know that this is a must fill column. Thus if a column is defined as CHAR(3) everyone should know that the column will always contain three characters. Defining the column as VARCHAR2(3) does not tell you anything about the data other than that the column may contain 0-3 characters.
Also, If a column is defined as CHAR the column should always be populated. One of the nice features of VARCHAR2 is that if the column is defined at the end of a table, there is no storage overhead until that column is actually populated. Thus if you have a table that has an identifier that is nine characters in length and will always be populated with nine characters, an attribute which describes the type of identifier which is contained in the first column and which must always be populated and is a must fill attribute, and another column which is descriptive and may vary in length or not be populated at time of insert; the following definition does not express the business semantics of the entity:
COL_CD VARCHAR2(9)
COL_TYP_TXT VARCHAR2(26)
COL_TYP_CD VARCHAR2(2)
The above definition also does not take advantage of inherent storage features of Oracle; notably there is a wasted place holder between COL_CD and COL_TYP_TXT and between COL_TYP_TXT and COL_TYP_CD. The next definition does take advantage of the storage features but does not represent the business semantics of the entity:
COL_CD VARCHAR2(9)
COL_TYP_CD VARCHAR2(2)
COL_TYP_TXT VARCHAR2(26)
The above definition does not waste space storing a place holder between COL_TYP_CD and COL_TYP_TXT if the COL_TYP_TXT may be null. The column separator will only be used when the column contains data. The below definition satisfies both the storage and business semantics issues:
COL_CD CHAR(9)
COL_TYP_CD CHAR(2)
COL_TYP_TXT VARCHAR2(26)
This may seem pedantic in nature until you consider the situation where there are 25 million rows in the table represented by the above entity. If each row has a NULL COL_TYP_TXT value then the first example wasted 25 million bytes of storage and 25 million bytes of memory if the full table is loaded into memory. This is an issue which cannot be ignored in high volume databases.
You may wish to know why it is important to define a must fill/always fill column as a CHAR to express the business semantics of an attribute. I can't give a definitive answer to that other than to say that it is just good database manners.
So please, continue to use CHAR when the shoe fits. Don't throw something away that has use just because it is not popular or in the mode.
Also, if I am mistaken in any of the above, please feel free to educate me.
Thanks.
-----Original Message-----
Subject: RE: Oracle on the use of VARCHAR2 vs. CHAR
Ignore if you already got this. This is just FYI.
-----Original Message-----
Below is a detailed answer to your VARCHAR2 or CHAR questions from our Database expert Tom Kyte. The short answer is VARCHAR2 is what you want to use. If you have any questions or want to discuss this in more detail let me know.
A CHAR datatype and VARCHAR2 datatype are stored identically (eg: the word 'WORD' stored in a CHAR(4) and a varchar2(4) consume exactly the same amount of space on disk, both have leading byte counts).
The difference between a CHAR and a VARCHAR is that a CHAR(n) will ALWAYS be N bytes long, it will be blank padded upon insert to ensure this. A varchar2(n) on the other hand will be 1 to N bytes long, it will NOT be blank padded.
Using a CHAR on a varying width field can be a pain due to the search semantics of CHAR.
Consider the following examples:
ops$tkyte@8i> create table t ( x char(10) ); Table created.
ops$tkyte@8i> insert into t values ( 'Hello' );
1 row created.
ops$tkyte@8i> select * from t where x = 'Hello';
X
Hello
ops$tkyte@8i> variable y varchar2(25)
ops$tkyte@8i> exec :y := 'Hello'
PL/SQL procedure successfully completed.
ops$tkyte@8i> select * from t where x = :y; no rows selected
ops$tkyte@8i> select * from t where x = rpad(:y,10);
X
Hello
Notice how when doing the search with a varchar2 variable (almost every tool in the world uses this type), we have to rpad() it to get a hit.
If the field is in fact ALWAYS 10 bytes long, using a CHAR will not hurt -- HOWEVER, it will not help either.
The only time I personally use a CHAR type is for CHAR(1). And that is only because its faster to type char(1) then varchar2(1) -- it offers no advantages.
If you just use varchar2 everywhere, no problem
My advice is, has been, will be very loudly stated as:
IGNORE THE EXISTENCE OF CHAR.
period. If you never use char, you never compare char to varchar2, problem solved.
And if you use char and compare a char(n) to a char(m) they will never compare either.
Just say NO TO CHAR.
**************************************************

Answer 1

Hi,
>>A CHAR datatype and VARCHAR2 datatype are stored identically (eg: the word 'WORD' stored in a CHAR(4) and a varchar2(4) consume exactly the same amount of space on disk, both have leading byte counts).
Ok, but on the other hands:
SGMS@ORACLE10> create table x (name char(10), name2 varchar2(10));
Table created.
SGMS@ORACLE10> insert into  x values ('hello','hello');
1 row created.
SGMS@ORACLE10> commit;
Commit complete.
SGMS@ORACLE10> select vsize(name),vsize(name2) from x;
VSIZE(NAME) VSIZE(NAME2)
         10            5
SGMS@ORACLE10> select dump(name),dump(name2) from x;
DUMP(NAME)                                         DUMP(NAME2)
Typ=96 Len=10: 104,101,108,108,111,32,32,32,32,32  Typ=1 Len=5: 104,101,108,108,111Cheers