The NUMBER datatype will use a varying number of bytes as well. There is one byte used to store the exponent and
one to 20 bytes to store the mantissa of the number. So depending on the number you store, you can use between two to 21 bytes of data.
The above gives you the information you need to decide how much storage space is required to store your number in the NUMBER and VARCHAR2 datatypes. Typically, the NUMBER datatype will require less bytes than the VARCHAR2 datatype unless the value is very small, i.e., one, two, three, etc. In the case where the value is one digit, the VARCHAR2 datatype will require one less byte than the NUMBER datatype. However, in today's systems, the storage requirements are typically not a determining factor here.
In most every case, the performance differences are negligable. The smallest unit of I/O is one database block. Unless you are using a very small block size, you still have to read that one block to read the value no matter which datatype you use, provided the block is not already in the cache. So the performance time spent reading the value is the same. If you are going to perform operations on the value and have to convert the value from one datatype to another, then you will incur CPU cycles for the conversion. For instance, you store the value in a VARCHAR2 and then want to perform arithmetic; that value must be converted to a NUMBER datatype first, either explicitly or implicitly.
However, with today's systems, the CPU cycles required are minimal so as to hardly be noticed. I suppose someone could come up with a scenario where the datatype conversions could make a difference, but I would say that such a case would be very rare in practice.
To me, the biggest influencing factors were outlined in my previous response. I really do not see storage requirements or performance to be the defining criteria, except in the most extreme cases.
Dig deeper on Oracle database design and architecture
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.