• If I might borrow an idea from CJ Date...I'd add a 0th rule that would take precidence over the other 4 listed in the article.  Rule 0 states "Do not use NULLs."

    Missing values are not allowed in true sets, any more than duplicates are.  As a data architect I am well aware of situations where we just don't have a piece of data, and in some cases I will include nullable columns, but this is the exception rather than the rule.  And the only reason I do it is because the available DBMS's (and the SQL standard) don't provide an acceptable way of dealing with missing information.

    The example of employee middle names is one where I would probably allow nulls because middle name is an incidental piece of data that isn't likely to be used except for fairly insignificant informational purposes.  However, if we change our focus to salary, and there are some employees without a salary, the most likely scenario is that salary information would belong in a seperate table from the other employee information and only those employees who have a salary would have a record there...

    This illustrates a major problem with SQL NULLS and the way they are used.  There are essentially two reasons for missing information.  The data is unknown, or the data is not applicable.  SQL NULLs lump both reasons together.  In reality, if an attribute is not applicable to a given record then that record (and all others to which the attribute is not applicable) is actually of a different type than the records to which the attribute does apply and should logically be placed in a different table.

    In addition to the problems pointed out in article, NULLs are a logical nightmare in aggregate functions.

    /*****************

    If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek

    *****************/