Data type in column definition

Question

Hi,
I create a table with column called "Direction of Travel code ".
The travel codes in the functional spec are numbers.
In the column definition which one is efficient to define the data type as number or varchar?
Code
1      
2      
3      
4      
5      
6      
7      
8      
9      
0

Answer 1

tijmen wrote:
Tubby wrote:
And then when you issue a query and ask for travel codes 2 through 10 the CBO can't determine that there are 8 values (cardinality wise) because you're not storing the data type in the format you should be storing it as. Statistics? Perhaps even histograms?
Simple testcase:
create table t1(x number(1)) as select mod(rownum, 10) from all_objects where rownum <= 100;
create table t2(x varchar2(1)) as select to_char(mod(rownum, 10)) from all_objects where rownum <= 100;
exec dbms_stats.gather_table_stats(user, 'T1', method_opt => 'FOR ALL COLUMNS SIZE 1');
exec dbms_stats.gather_table_stats(user, 'T2', method_opt => 'FOR ALL COLUMNS SIZE 1');Tried a few simple statements against those (where x = N, where x between N and M), using either literals or bind values. I didn't see any difference in the explain plan...
Not to mention what happens when someone decides to put an "A" in your travel code that should be only numbers, it will eventually happen.Yes, and that's an input error that should be caught by a database constraint (and possibly even before that by the application). Who knows, the codes 0 and 5 might become obsolete as well with changing business rules. Your number datatype is not going to protest when someone still uses them. Hey, maybe even tomorrow someone from the business will come in and demand for the codes 'a' to 'd' to be created. Histograms, application code and database constraints (which all have side effects and add complexity to the system) as opposed to declaring the data type as a NUMBER (which it is). Doesn't seem like a really good argument for intentionally choosing the wrong data type. Well, at least you didn't suggest a trigger in there as well.
>
I'm not saying you should use a char type instead of a number. I'm saying I doubt there's much difference as far as the database is concerned, and I would base the decision on how it works out on the application and business side.As you've found out, the OP stated the functional specs define this as a number. IF in the future the specs change and a business analyst mandates that this support characters as well then the data type gets changed to support the new requirement, no database constraints to remove, no application code to remove, etc...