T字形ER手法でnullを認めない理由(4)

今回はSQLが文字列のnullをどう扱うかを整理する。

文字列のnull

先週、後輩に「SQLで文字列の連結演算子を使って苗字と名前を連結すると、答えが空になってしまうのですが...」という相談を受けた。
検索対象にしたテーブルで、下の名前にnullが混入しているために、

"山田" ＋ null = null

になってしまっていたのだが、やはりホスト言語からの類推で、

"山田" ＋ null = "山田"

となると思っていたとのこと。
SQLのnullは空文字列のようなものではない。
あくまでも「何か値があるが、それが何なのか今は分からない」というものだと考えなくてはならない。
"山田"に何だか分からないものを足したから、答えも何だか分からない、ということ。
"山田"にnullを足した答えが"山田"のままなのであれば、nullの実際の値が空文字列であったということになってしまう。

この挙動は、数値のnullと同じく、値が不明(=unknown)な値に対しては正しい動きだが、値がありえない(=undefined)な値に対しては「直感に反する」ものになっている。

ホスト言語にもnullはあるが...

ホスト言語にもnullはあるが、別の文字列と連結した時にnullになってしまうような言語はないだろう。
このことは、データベースにnullを保存してしまうと、その処理をSQLで行うかホスト言語で行うかによって結果が違ってしまうことを意味する。
これはnullを極力回避すべき理由としてけっこう重要だと思う。

続く。