Unless I'm completely missing something, nobody has pointed out the problem with TysonLPrice's statement about the blood bank:
"You would not want a blood bank to match a sample with Null blood type (not yet entered) to a patient with Null blood type (not yet identified) "
NULLS <> NULLS so a join would not match these values at all. That is part of the purpose of the NULLS. If you however set these values to a non-null default value, say an empty string, the join would succeed and you would get the matching rows resulting in an obvious disaster at the blood bank. The only way you match on NULLS is to explicitly say in a query "where columnValue IS NULL".
So while it seems to me Tyson's argument was to point out the flaws in using NULLS, it actually proves how valuable they are.
While I absolutely hate dealing with them on the programming side, I think they are a necessary evil in many cases.
However, I will say that many times DBAs are lazy and allow everything to be NULL when it really should be a required value. For example, an Item.Qty field in an ordersItems table should probably always have some numeric value since an ordered item with no quantity makes no sense. Yet I've worked with many databases that allow this. This throws the onus on the programmer to handle NULLs in fields that he really should not have to worry about. It's those situations that give NULLs a bad wrap I think. In the end, you have to assume everything may be NULL and code for it when reading the data in initially to prevent run-time exceptions.
If I've misunderstood Tyson's example hopefully someone will point that out. I felt it was important to post this so no one would leave this thread thinking NULLs = NULLs in a join.
J