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

And what about:

select null from dual union select null from dual;

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

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?!!!”)

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

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

@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…).

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

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