Apparently oracle doesn’t seem to distinguish between empty strings and nulls. E.g.
Select name from TABLE_A where id=100;
ID NAME
100 null
Update TABLE_A set NAME='' where id=100;
SELECT -->
ID NAME
100 null
SELECT length(NAME) FROM TABLE_A WHERE id=100;
null
I can’t think of any good reason why Oracle would be built to behave this way (does it do this in sqlplus as well?-I’m accessing through a java interface, the article referenced used a php client).
Wouldn’t you at least want to distinguish 0 length from undefined length? Is this a known issue? Intentional behavior for some specific purpose? A long-running dispute in database theory? What gives?
(This was prompted by Matt Solnit’s answer to this question.)
Oracleis very very very old.Back in
80'swhen it was developed (and before there were any standards) they thought is was a good idea, and given then wayOraclestores its values, it really was.Here’s how
Oraclestores data (taken from the documentation):No datatype is stored within the data, only the data length and the data itself.
If the
NULLoccurs between two columns with values, it’s stored as a single byte meaning column has length0(actually,0xFF). TrailingNULLs are not stored at all.So to store the value
'test',Oracleneeds to store 5 bytes:04 74 65 73 74.However, to store both an empty string and a
NULL,Oraclejust needs to set data length to0.Very smart if your data are to be stored on
20 Mbhard drives that cost5,000$each.Later, when the standards appeared, it wasn’t such a good idea anymore, but by that time there already were lots and lots of code relying on
NULLand''being the same thing.Making
VARCHARto do such a distinction will break tons of code.To fix it, they renamed
VARCHARtoVARCHAR2(which is not a part of any standard), stated thatVARCHAR2will never distinguish between aNULLand an empty string and urged everybody to use this datatype instead.Now they are probably waiting for the last person who used a
VARCHARinOracledatabase to die.