Macheist mania

Now that I discovered the site, the hype is probably already over it’s top. But I find it intriguing. You buy a bundle of Mac OS X applications with a huge discount. And you support some charity organizations along the way. And if you’re lucky, some apps wil be added along the way. Because a minimum number of downloads is reached, or just for fun. And of course, the offer is limited.

And they call it Macheist. At the time of writing they’re offering a Nanobundle. I’m still not sure what’s the difference between the nanobundles and the regular ones, but I’ll find out in time.

Check it out at http://www.macheist.com and see for yourself if the $20 is well spent on this software collection. And if the requirements will be met for Monkey Island, of course!

Something about null values in Oracle SQL

Something I’ve posted before…. but I thought it was time to rewrite it a little.

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 doesn’t even equals to itself.
And because of that, 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 you’re bound to encounter sooner or later. 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 from nulls where NOT( value1 = 'A collection of ');

  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 row 2 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.

Execution 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)

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)
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 , nvl2( value1 , 'this column is not null' , 'and this columns is NULL' ) test from   nulls;

        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!

By using this site you acknowledge the use of cookies (which are mostly harmless, btw) More information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below you are agreeing to these settings.

Close