NULLを「とりあえず許容」にしてはいけない理由とDB設計の判断軸

はじめに この記事では、NULLをカラムに許容するかどうかの設計判断を整理します。 「とりあえずNULL許容にしておけば後で困らない」という考えは、設計としては危険です。 NULLの意味が曖昧なまま積み重なると、クエリのバグやアプリ側の防御コードが増え、テーブルの読み解きが難しくなります。 NULLが持つ意味は1つではない NULLは「値がない」という状態を表しますが、「値がない理由」は複数あります。 未入力：まだ値を入力していない 不明：値があるはずだが把握できていない 適用外：そのカラムの概念自体がこのレコードに当てはまらない 削除済み：参照先が消えた 同じカラムにこれらの意味が混在すると、クエリを書く側は何を意味するNULLなのかを判断できません。 例として、次のようなカラムを考えます。 CREATE TABLE orders ( id INT NOT NULL AUTO_INCRE

[paradoxparanoic]

取り敢えずnot nullの方が問題が少ない。nullと0やブランクを使い分ける必要がある場合だけnull許容にすればいい