"On the other hand, there are those who would recommend a less dramatic method of dealing with NULL, namely: "learn how to use them properly, and minimize their use where practical."

WOW FINALLY, Someone to voice and understand the true need, and nature of NULL.

I have long argued that there are real world needs for null when the data is truly not known. As an auction company we take in 10's of thousands of items each year, and write detailed condition reports on them. We also create highly detailed attribute lists as part of the condition report.

So as an example if we created defaults of say "No" for an attribute like "Air Conditioning", it could lead to potentially damaging results.

If the condition report writer failed to check the A/C, there would be nothing to alert anyone that the attribute had been missed, as it would look like the asset does not have A/C. If the item does in fact have A/C and the writer simply missed it the end result would be a costly devaluation of the asset. In this case NULL, is valuable, and with 148 distinct attributes for a Truck Tractor or Trailer, as an example, I can only imagine (or rather can't imagine) the nightmare of maintaining and querying this in 6NF. While it is true that this could be handled in the interface by say not allowing the input of a condition report until all the questions are answered, there are distinct and real business reasons why you would not want do that, so null becomes the best solution. The only other course is to set the defaults to "Unanswered" but, then what about numeric fields?

Clearly; when appropriate, defaults and normalization should be used, but I think it was quite elegantly proven in this article that when used thoughtfully and with careful design NULL is a very powerful tool!