I'm not talking about how you application is designed. If your
applications allows an employee to be entered without a position in the
company, it is a bad design.
If a manager at my company hired someone, and did not know what work the
new-hire would be doing, well I'd really need to ask why they were hire,
right before I fired the manager for hiring someone for no apparent
No fake row needed, a dept is required!
So far the weather guy has the best example of using nulls, and again, I'd
receive a null from the remote weather bug, but I wouldn't put that
garbage in my database!
I would NOT use -9999 for the missing dept, my application would flat-out
require a department. If the data entry clerk wants to add some dummy
department because they hire lots of people for no reason, then so be it.
Better example anyone?
And FAX numbers, what about home phone, not many of those lately either.
Notice that phone numbers in general are an odd sort, especially because
of the variant types around the world. So phone numbers should be strings,
not numeric. Therefore I think blank spaces would be reality. Uh, whats
there FAX number? It's blank. That means they don't have a FAX number. But
if you decide to use Null, then in binary terms it is uninitialized
garbage. It adds to your development time, your debugging time, and your
processing time. Not to mention the possibility of inconsistent results
when retrieving data. Same applies to middle names, you simply need to
think about each field of data, and what it really means to the
You guys who disagree on this: I know that this is what you were taught in
school, and I know all the uses for null values. I just think the teaching
is wrong. Sometimes teachers don't think, and most of the time students
don't think. But when you become experienced, you should think.
The words of Tony Hoare: The man who developed the most widely used sort
algorithm around the world.
Tony said: "I call it my billion-dollar mistake. It was the invention of
the null reference in 1965. At that time, I was designing the first
comprehensive type system for references in an object oriented language
(ALGOL W). My goal was to ensure that all use of references should be
absolutely safe, with checking performed automatically by the compiler.
But I couldn't resist the temptation to put in a null reference, simply
because it was so easy to implement. This has led to innumerable errors,
vulnerabilities, and system crashes, which have probably caused a billion
dollars of pain and damage in the last forty years. "
It's unbelievable that nobody agrees with me, or even sees my point,
> Exactly the point. Michael, NULL *is* information. It means "unknown" and
> that is in itself useful information. A common example:
> A new employee is hired but which department she will work in is unknown.
> the data entry person enters all the known information and leaves the rest
> until it has been clarified.
> The alternative is even worse than the so-called NULL problem and the
> alleged difficulty of querying against NULLable columns: in a case like
> described above, the only way to handle it is to create a fake row in the
> foreign-key table, for "Department Zero" or somesuch. That immediately
> every query into a more complex beast that it would otherwise have been.
> Every single query must exclude this "zeroth" row; join a few tables all
> exhibiting this problem and things get really crazy.
> Not to mention the fact that these "zeroth" rows falsify reality and
> fiction with fact. Even worse, the "-99999" approach means that you can't
> impose a constraint on the column (such as "must be a positive integer".
> And finally, I cannot believe that you really mean "no NULLS ever". Surely
> you mean only FKs. Otherwise, how would you handle fax numbers for people
> with no fax, or middle names for people with none?