 <p>It is useful to mark "unknown" or missing values.</p> <p>For instance, if you're storing people, and one of the fields is their birthday, you could allow it to be <code>NULL</code> to signify "We don't know when he was born".</p> <p>This is in contrast to having non-nullable fields where, for the same type of meaning, you would need to designate a "magic value" which has the same meaning.</p> <p>For instance, what date should you store in that birthday field to mean "we don't know when he was born"? Should 1970-01-01 be that magic value? What if we suddenly need to store a person that was born on that day?</p> <p>Now, having said that, <code>NULL</code> is one of the harder issues to handle in database design and engines, since it is a propagating property of a value.</p> <p>For instance, what is the result of the following:</p> <pre><code>SELECT * FROM people WHERE birthday &gt; #2000-01-01# SELECT * FROM people WHERE NOT (birthday &gt; #2000-01-01#) </code></pre> <p>(note, the above date syntax might not be legal in any database engine, don't get hung up on it)</p> <p>If you have lots of people with an "unknown" birthday, ie. <code>NULL</code>, they won't appear in either of the results.</p> <p>Since in the above two queries, the first one says "all people with criteria X", and the second is "all people without criteria X", you would think that together, the results of those two queries would produce all the people in the database.</p> <p>However, the queries actually say "all people with a known and definite criteria X."</p> <p>This is similar to asking someone "am I older than 40?" upon which the other person says "I don't know". If you then proceed to ask "am I younger than 41?", the answer will be the same, he still doesn't know.</p> <p>Also, any mathematics or comparisons will produce <code>NULL</code> as well.</p> <p>For instance, what is:</p> <pre><code>SELECT 10 + NULL AS X </code></pre> <p>the result is <code>NULL</code> because "10 + unknown" is still unknown.</p>