Comments on: Is this a bug in Analytical Functions? NULL is supposed to be UNEQUAL to NULL? http://technology.amis.nl/2006/10/13/is-this-a-bug-in-analytical-functions-null-is-supposed-to-be-unequal-to-null/ Friends of Oracle and Java Wed, 17 Dec 2014 14:54:39 +0000 hourly 1 http://wordpress.org/?v=4.0.1 By: Marco Gralike http://technology.amis.nl/2006/10/13/is-this-a-bug-in-analytical-functions-null-is-supposed-to-be-unequal-to-null/#comment-3905 Sat, 14 Oct 2006 12:42:40 +0000 http://technology.amis.nl/blog/?p=1356#comment-3905 Oracle is just following the rules layed out by ANSI SQL.

]]>
By: Patrick Sinke http://technology.amis.nl/2006/10/13/is-this-a-bug-in-analytical-functions-null-is-supposed-to-be-unequal-to-null/#comment-3904 Sat, 14 Oct 2006 10:45:54 +0000 http://technology.amis.nl/blog/?p=1356#comment-3904 I think, though, that you alway should see the result of those queries from the point of view from the end user. And what an end user wants to see is not

DEPTNO COUNT(*)
===== =======
30 6
“null” 1
“null” 1
“null” 1
“null” 1
“null” 1
“null” 1

20 5
10 1

That’s just not convenient. Any query I would write for an end user that yields this result would not be accepted by that user. He would want me to rewrite the query so that all the ‘null’ or ‘unknown’ departments to be put together in one result, because separate records with count=1 have no meaning at all.
So probably Oracle has made the choice to handle nulls like that, and my opinion is that they made the most logical (or call it: intuitive) choice :)

]]>
By: Mr. Ed http://technology.amis.nl/2006/10/13/is-this-a-bug-in-analytical-functions-null-is-supposed-to-be-unequal-to-null/#comment-3903 Sat, 14 Oct 2006 10:40:19 +0000 http://technology.amis.nl/blog/?p=1356#comment-3903 Giving each NULL value its own group seems unwieldy, especially if you have an N-column GROUP BY, and then all-but-1, all-but-2, …, or all-but-(N-1) of those columns have NULL values.

And what about:

select null from dual union select null from dual;

It only returns 1 row. Should GROUP BY be any different?

]]>
By: Marco Gralike http://technology.amis.nl/2006/10/13/is-this-a-bug-in-analytical-functions-null-is-supposed-to-be-unequal-to-null/#comment-3902 Fri, 13 Oct 2006 23:34:24 +0000 http://technology.amis.nl/blog/?p=1356#comment-3902 Hmmmm, even wordpress has problems with (or NOT?)

;-)

Second try…

Who argues for outcome:

DEPTNO COUNT(*)
===== =======
30 6
“null” 1
“null” 1
20 5
10 1

(hopefully it will now print correctly, otherwise “Lucas Help?!!!”)

]]>
By: Marco Gralike http://technology.amis.nl/2006/10/13/is-this-a-bug-in-analytical-functions-null-is-supposed-to-be-unequal-to-null/#comment-3901 Fri, 13 Oct 2006 23:29:37 +0000 http://technology.amis.nl/blog/?p=1356#comment-3901 Who argues for outcome:

DEPTNO COUNT(*)
——— ———–
30 6
1

]]>
By: Marco Gralike http://technology.amis.nl/2006/10/13/is-this-a-bug-in-analytical-functions-null-is-supposed-to-be-unequal-to-null/#comment-3900 Fri, 13 Oct 2006 23:25:56 +0000 http://technology.amis.nl/blog/?p=1356#comment-3900 From “An introduction to Database Systems” (International Editon – Eighth Edition) by C.J.Date:

Possible meanings / reasons why there is a absence of a value (page 577):

– value unknown
– value not applicable
– value does not exist
– value undefined
– value not supplied
– …

(page 595): Aggregate Operators:

The SQL aggregate operators (SUM,AVG,etc.) do not behave in accordance with the rules for scalar operators explained in Section 19.2, but instead simply ignore any nulls in their argument (except for count(*), where nulls are treated as if they were regular values). Also if the argument to such an operator happens to evaluate to an empty set, COUNT returns zero; the other operators all return NULL. (As noted in Chapter 8, this bahaviour is logically incorrect, but it is the way SQL is defined.)

MG

]]>
By: Marco Gralike http://technology.amis.nl/2006/10/13/is-this-a-bug-in-analytical-functions-null-is-supposed-to-be-unequal-to-null/#comment-3899 Fri, 13 Oct 2006 22:58:09 +0000 http://technology.amis.nl/blog/?p=1356#comment-3899 @Patrick: “…and the employees that are not in any department are summed”, but this is the problem using NULL Patrick, you are assuming that they “are not in any department”. A NULL coudl also imply “we KNOW the belong to a department but it is UNKNOWN to us in which…”

@Jurgen: you don’t want to get into that one… It could be the difference between a salary check with a VALUE on it at the end of the month or a salary check without a VALUE… (you could think of more worse-case real life example of course…you did a 911 call, which is registered in a database, which triggers…).

]]>
By: Marco Gralike http://technology.amis.nl/2006/10/13/is-this-a-bug-in-analytical-functions-null-is-supposed-to-be-unequal-to-null/#comment-3898 Fri, 13 Oct 2006 22:49:32 +0000 http://technology.amis.nl/blog/?p=1356#comment-3898 If think your

select deptno
, count(*)
from emp
group
by deptno

is a great example of Oracle desperatly wanting to give answer where it should not give one.

A department with value NULL is not equal to a department with value NULL. Also a nice example why one should avoid NULL’s

]]>
By: Marco Gralike http://technology.amis.nl/2006/10/13/is-this-a-bug-in-analytical-functions-null-is-supposed-to-be-unequal-to-null/#comment-3897 Fri, 13 Oct 2006 22:45:42 +0000 http://technology.amis.nl/blog/?p=1356#comment-3897 “The results also suggest an equality between NULL…”

From the viewpoint of Oracle’s implementation of NULL’s, it does. Your “count(*)” spoils the soup. See the examples (nice post) of beter nullogy on http://www.databasedesign-resource.com/null-values-in-a-database.html. I think we are dealing with a “this is an error in the COUNT function: Any column would give the same COUNT result…” problem here.

Nice links found regarding nullogy:

*) Fabian Pascal: http://www.dbdebunk.com/page/page/1396241.htm
*) Hugh Darwen: http://web.onetel.com/~hughdarwen/TheThirdManifesto/Missing-info-without-nulls.pdf
*) http://www.dbdebunk.com/about.html

]]>
By: Paweł Barut http://technology.amis.nl/2006/10/13/is-this-a-bug-in-analytical-functions-null-is-supposed-to-be-unequal-to-null/#comment-3896 Fri, 13 Oct 2006 16:15:55 +0000 http://technology.amis.nl/blog/?p=1356#comment-3896 This is rather natural as its defined in ANSI SQL. Similar effect will be with DISTINCT clause, NULL is returned only once.

]]>
By: Jurgen Kemmelings http://technology.amis.nl/2006/10/13/is-this-a-bug-in-analytical-functions-null-is-supposed-to-be-unequal-to-null/#comment-3895 Fri, 13 Oct 2006 15:37:34 +0000 http://technology.amis.nl/blog/?p=1356#comment-3895 It feels indeed intuitively correct. But what could theoretically be against having a group of undefined objects?

]]>
By: Patrick Sinke http://technology.amis.nl/2006/10/13/is-this-a-bug-in-analytical-functions-null-is-supposed-to-be-unequal-to-null/#comment-3894 Fri, 13 Oct 2006 15:27:49 +0000 http://technology.amis.nl/blog/?p=1356#comment-3894 I don’t think you can say that this function suggests that null = null. What you show here is the count of employees per department. The function sums op the employees that are in dept 30 (6), in dept 20 (5), in dept 10 (1), and the employees that are not in any department are summed: 2 employees apply to that condition.
So in my opinion it’s not a bug. On the contrary, it is a very correct behaviour againts null values in these functions!

]]>
By: Harm Verschuren http://technology.amis.nl/2006/10/13/is-this-a-bug-in-analytical-functions-null-is-supposed-to-be-unequal-to-null/#comment-3893 Fri, 13 Oct 2006 14:59:11 +0000 http://technology.amis.nl/blog/?p=1356#comment-3893 NULL is undetermined
Ergo: NULL != NULL

]]>