The problem is a bit more subtle. NULL is often used with two distinct meanings: - I know that Theodore Roosevelt has no middle name. - I don't know what The

The problem is a bit more subtle. NULL is often used with two distinct meanings: - I know that Theodore Roosevelt has no middle name. - I don't know what Theodore Roosevelt's middle name is The semantics of each case are different in a subtle but important way. Consider the following two predicates 'Jim' = [no value] vs 'Jim' = [I don't know] The former predicate is obviously false. 'Jim' is not equivalent to a non-existent value. The latter predicate however, can't be assigned a truth value. It's entirely possible that the unknown value could later turn out to be 'Jim'. The key issue is that SQL treats NULL values according to the latter ('I don't know') rule and ternary (Kleene) logic, as TFA discusses. That, in turn means that using NULL to represent [no value] will lead to painful and hard to diagnose logic bugs (e.g., WHERE x = 1 OR x != 1 not returning all records). [edit: clarifying why bugs will arise]