As you know, I am not a huge fan of NULL values in databases. There are times, when I do like them (such as with undefined date/time fields), but for the most part, I think they are horrible, cause confusion, and create much more overhead than they are worth from any sort of business requirements standpoint. I have gotten a lot of heat for this, but every now and then, someone like Alf Pedersen reaches out to me to lend some moral support.
Alf Pedersen, who has spent over 30 years in the computer and database world, has written some really good stuff on database design. But, more specifically related to my feelings, he has a well written article on the downside of allowing NULL values in your database schema. If you don't agree with me, maybe his article, NULL values in a database: A programmer's nightmare, will change your mind.
Thanks Alf for your insight and your moral support :)
If I could make one note about his article, it would be about the COUNT() and SUM() stuff. In his examples, he is demonstrating that NULL values in the database return "unexpected" results (for those not 100% familiar with the database schema). While this is true, the fact that COUNT() and SUM() (and other aggregates) do not take into account NULL values can certainly be leveraged to our advantage. For instance, you can use CASE statements inside of your aggregates to conditionally exclude row values by returning NULL. This is especially powerful when you need to run several different types of conditional aggregates over a single group.
But, of course, this type of logic has nothing to do with the actual value in the database row and can still be done for a database column that doesn't allow NULL values.