Skip to Main Content
  • Questions
  • char (10) data type hosting numeric data for natural keys

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, sunny.

Asked: February 16, 2017 - 4:59 pm UTC

Last updated: February 20, 2017 - 1:17 am UTC

Version: 11g

Viewed 1000+ times

You Asked

Hi,

Can you please provide some guidance on the possible performance issue one might have in creating a char(10) data type that hosts natural keys?

Also, I'm baffled by the following results..


THIS WORKS FINE even char(10) blank pads the remaining digits, how is this possible..

how is 'N/A' = 'N/A ' -- See space

select * from
table
where
column='N/A'

Thx

and Connor said...

I think your second sentence answers the first. CHAR can lead to correct but non intuitive results.

In a char(10) column: 'X', 'X[space]', 'X[space][space][space][space]' are all ultimately stored the same way, ie, X plus 9 spaces.

Rating

  (5 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

char(10) data type that hosts numeric natural keys?

sunny aleti, February 17, 2017 - 8:48 pm UTC

Can you please provide some guidance on the possible performance issue one might have in creating a char(10) data type that hosts numeric natural keys?
Connor McDonald
February 18, 2017 - 4:37 am UTC

Here's a familiar example when number and strings are used interchangably.

SQL> create table t
  2    ( pk char(10),
  3      data varchar2(100)
  4    );

Table created.

SQL>
SQL> insert into t select rownum, rpad(rownum,80,'x')
  2  from dual
  3  connect by level <= 100000;

100000 rows created.

SQL>
SQL> alter table t add primary key ( pk );

Table altered.

SQL>
SQL> set autotrace traceonly explain
SQL> select * from t
  2  where pk = 123;

Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    64 |   241   (1)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |     1 |    64 |   241   (1)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(TO_NUMBER("PK")=123)




Because I mixed and matched datatypes, I silently disabled the use of my index on that query.

Opt Behavior

A reader, February 18, 2017 - 5:54 am UTC

Yes that's what I expect as per experience. .
But this is a proof , a stupid behavior of oracke transformation. .
Since it is obliged to convert why converting the pk to number instead of the to_char of 123? Since he previously *know * that pk is of character datatype? ?? How *dare* he try for instance converting to number of 'abc34fu.' ??
What I expect really from oracle is to have in explain trace ..Where pk=To_char (123)

So since the correct one must be '123 '
But unless it's more logical behavior.
And hence the qry returns no rows.

Certainly we know that the correct qry is
..Where pk = '123 '

Connor McDonald
February 20, 2017 - 1:17 am UTC

It would be pretty risky for us to start throwing datatype conversion functions around values supplied by the end user. You supplied this example:

where PK = abc34fu

Do you *really* want me silently converting that to:

where PK = 'abc34fu'

What if "abc34fu" is a plsql function ?

Follow up

A reader, February 20, 2017 - 6:52 am UTC

Optimizer /oracle Also know whether the other side is a Function or not..
He also knows that pk is of varchar2 datatype so it is more logic to convert any other outside dictionary introduced variable to meet that definition.

Different strings can mean same number

A reader, February 20, 2017 - 8:48 am UTC

Hi

I have allways doubted that Oracle is doing conversions from character to numbers because there could be leading zeroes in character strings.

Now '123' = 123 and also
'0123' = 123.


Different strings can mean same number

A reader, February 20, 2017 - 8:50 am UTC

Hi

I have allways doubted that Oracle is doing conversions from character to numbers because there could be leading zeroes in character strings.

Now '123' = 123 and also
'0123' = 123.