 <p>The null in most programming languages is considered "known", while NULL in SQL is considered "unknown".</p> <ul> <li>So <code>X == null</code> compares X with a known value and the result is known (true or false).</li> <li>But <code>X = NULL</code> compares X with an unknown value and the result is unknown (i.e. NULL, again). As a consequence, we need a special operator <code>IS [NOT] NULL</code> to test for it.</li> </ul> <p>I'm guessing at least part of the motivation for such NULLs would be the behavior of foreign keys. When a child endpoint of a foreign key is NULL, it shouldn't match any parent, even if the parent is NULL (which is possible if parent is UNIQUE instead of primary key). Unfortunately, this brings many more <a href="http://thoughts.j-davis.com/2009/08/02/what-is-the-deal-with-nulls/">gotchas</a> than it solves and I personally think SQL should have gone the route of the "known" null and avoided this monkey business altogether.</p> <p>Even E. F. Codd, inventor or relational model, later indicated that the traditional NULL is not optimal. But for historical reasons, we are pretty much stuck with it.</p>