第22回: NULL設計とデフォルト値 — 「意味のないNULL」がバグを生む前に

(Updated: )
1 min read

章: 第5章: 設計品質を上げる

「このカラム、NULLでいいや」が後から問題になっていませんか？

カラムに深く考えずNULLを許可した結果、アプリ側で if ($value !== null) が乱発され、仕様の解釈が人によって異なるトラブルが起きることがあります。「このNULLは未入力なのか、削除済みなのか、不明なのか？」が曖昧なまま設計が進むと、バグの温床になります。

NULL設計とデフォルト値を最初に明確にしておくことが、アプリ側の分岐をシンプルに保つ最短ルートです。

NULLを許可する基準を決める

NULLを許可するかどうかは、「そのカラムに値が存在しない状態が業務上ありうるか」で判断します。迷ったときは次の比較表を参考にしてください。

カラムの性質 NULL許可 推奨設計
必ず値が入るべき項目（名前・メールなど） NG NOT NULL + バリデーションで保証
任意入力項目（自己紹介文など） OK NULL を「未設定」の意味で使う
フラグや状態（公開・非公開など） NG NOT NULL DEFAULT 0 などデフォルト値を設定
外部キー（任意の関連） OK NULL を「関連なし」の意味で使う
削除日時（論理削除） OK NULL = 未削除、値あり = 削除済み

チェックポイント: テーブル設計レビュー時に「このNULLは何を意味するか、1行で説明できますか？」と問いかけてみてください。説明できないNULLは設計の見直しサインです。

実際のコードサンプル


CREATE TABLE profiles (
  id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  user_id BIGINT UNSIGNED NOT NULL,
  bio TEXT NULL,
  is_public TINYINT(1) NOT NULL DEFAULT 0
);

まとめ & 次のステップ

  • NULLを許可するカラムには「このNULLが意味すること」をコメントやドキュメントに残す
  • フラグや状態値は NOT NULL DEFAULT を使い、NULLを混入させない
  • 任意入力項目は NULL 許可で「未入力」を表現し、空文字との混在を避ける
  • 既存テーブルのNULL設計を見直すときは SHOW FULL COLUMNS FROM テーブル名; から現状把握を始める
  • 設計段階で「NULLを許可する理由を列ごとに1行で言える」状態を目標にする

次回は 正規化と非正規化の判断 を学びます。常に正規化が正解とは限らない理由と、パフォーマンスとのバランスを取る判断基準を解説します。

Related Articles