The UNKNOWN null.

0 0

We all are at least a bit aware of the awkward behaviour of NULL in Oracle. But it still is difficult every time we encounter it in a function or where-clause.
Some examples to keep in mind when comparing NULL values:

1. null equals what?

Null equals nothing, in fact. It equals even not to it self.

And a condition does not always behave in the way you would expect.

Let’s start straightforward.

a := 10

a is null		results in		FALSE
a is not null		results in 		TRUE

a := null

a is null		results in 		TRUE
a is not null		results in		FALSE

We’ve all been there, done that and got ourselves the t-shirt.

a := null
b := null

This is a situation that might very well occur. Both a and b are null. Let’s compare it!

select 'x' from dual where a = b;

What is the result? FALSE?

Wrong! But it’s certainly not TRUE either. This expression results to UNKNOWN. And that state is a very dangerous one to be in!

Because UNKNOWN acts very similar to FALSE you might be tricked in thinking that they always behave the same. And that is not true. When a condition evaluates to UNKNOWN, no rows will be returned. In that sense it is similar. But look at this:

SQL> create table nulls( id number(9), value1 varchar2(20));

Table created.

SQL> insert into nulls values ( 1, 'A collection of ');

1 row created.

SQL> insert into nulls values( 2, null );

1 row created.

SQL> insert into nulls values( 3, 'something else');

1 row created.

SQL> select id
  2  from nulls
  3  where value1 = 'A collection of '
  4  /

        ID
----------
         1

That is exactly what we expected. “Where value1 = ‘A coll…’ ” evaluates to TRUE, so a row is returned, and “Where value1 = null” evaluates to UNKNOWN. No row is returned. Finally, “Where value1 = ‘something else’ “, evaluates to FALSE and no row is returned. All expected behaviour.

SQL> select id
  2  from nulls
  3  where NOT( value1 = 'A collection of ') 
  4  /

        ID
----------
         3

If we place a NOT operator around the conditions, the difference becomes clear. TRUE has become FALSE, FALSE has become TRUE, and UNKNOWN… is still UNKNOWN. And hence it is not displayed.

2. Nulls in indexes

I’ve created a table with one varchar2 column and 5000 records. The column contains a normal B-Tree index (tst1) and a function based-index tst2 (with function “where NVL( value1, ‘|empty|’ )”. One record is NULL, and unfortunately, that is exactly the one I am looking for. How does this affect performance?

SQL> select count(*) from psi_test where value1 is null;

1 row selected.

Explain plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=11 Card=1 Bytes=11)
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'PSI_TEST' (TABLE) (Cost=11 Card=509 Bytes=5599)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
         37  consistent gets
          0  physical reads
          0  redo size
        228  bytes sent via SQL*Net to client
        276  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL> select count(*) from psi_test where nvl(value1, '|empty|') = '|empty|';

1 row selected.

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=11)
   1    0   SORT (AGGREGATE)
   2    1     INDEX (RANGE SCAN) OF 'TST2' (INDEX) (Cost=2 Card=510 Bytes=5610)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          3  consistent gets
          2  physical reads
          0  redo size
        228  bytes sent via SQL*Net to client
        276  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL>

As you see, the optimizer does a full table scan on the first example, and an index range scan on the second. Of course, this is a very basic example, but it explains the idea.

3. null functions

NVL is well-known, it’s been there for ages. The function NVL returns the value of its second argument if its first argument is null.

SQL>  select value1, nvl( value1, '!! NULL values....' ) from nulls;

VALUE1               NVL(VALUE1,'NULLVALU
-------------------- --------------------
A collection of      A collection of
                     !! NULL values....
something else       something else

Powerful, very convenient, so often used.
And what if you want to determine the returned value based on whether an expression is null or not null? NVL is not so useful for that. But NVL2 is. NVL2 has not two but three arguments. The first is the tested value. If that is not null, the second expression is returned. If it’s null, the third expression is returned.

Example:

SQL> select id
  2  ,      nvl2( value1
                , 'this column is not null'
                , 'and this columns is NULL' ) test
  3* from   nulls
SQL> /

        ID TEST
---------- ------------------------
         1 this column is not null
         2 and this columns is NULL
         3 this column is not null

I think these little examples cover most of the issues you can encounter with null values. Don’t get tricked by a null!

About Post Author

Patrick Sinke

patrick.sinke@amis.nl

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Related posts:

Simulating sampling in PL/SQL Rule based in Oracle 10g Pimp you SQL Developer Best practices suck! ODTUG Kaleidoscope 2009