Home/ Questions/Q 8148681
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T14:41:39+00:00

Let’s suppose that x is some variable that has any value other than null

  • 0

Let’s suppose that x is some variable that has any value other than null, say 4, as an example. What should the following expression return?

x != null

In just about every programming language I have ever worked with (C#, Javascript, PHP, Python), this expression, or an equivalent expression in that language, evaluates to true.

SQL implementations, on the other hand, all seem to handle this quite differently. If one or both operands of the inequality operator are NULL, either NULL or False will be returned. This is basically the opposite of the behavior that most programming languages use, and it is extremely unintuitive to me.

Why is the behavior in SQL like this? What is it about relationaly database logic that makes null behave so much differently than it does in general purpose programming?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The null in most programming languages is considered “known”, while NULL in SQL is considered “unknown”.

    • So X == null compares X with a known value and the result is known (true or false).
    • But X = NULL compares X with an unknown value and the result is unknown (i.e. NULL, again). As a consequence, we need a special operator IS [NOT] NULL to test for it.

    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 gotchas than it solves and I personally think SQL should have gone the route of the “known” null and avoided this monkey business altogether.

    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.

    • 0