シードデータにおけるNullableカラムの処理

Nullableカラムの動作

実世界のデータベースには値がオプションのカラムがあります。シードジェネレーターは制御された確率でnullableカラムにNULLを挿入することでこれをシミュレートします。

Nullable検出の仕組み

パーサーは各カラム定義でNOT NULL制約を確認します：

• VARCHAR(255) NOT NULL → 常に値を受け取る
• VARCHAR(255)（NOT NULLなし）→ 行あたり約10%の確率でNULL
• INTEGER DEFAULT 0（NOT NULLなし）→ 行あたり約10%の確率でNULL

例

CREATE TABLE employees (
  id SERIAL PRIMARY KEY,
  first_name VARCHAR(100) NOT NULL,
  last_name VARCHAR(100) NOT NULL,
  middle_name VARCHAR(100),       -- nullable
  phone VARCHAR(20),              -- nullable
  department VARCHAR(50) NOT NULL,
  notes TEXT,                     -- nullable
  hire_date DATE NOT NULL
);

100行の生成データでは、middle_name、phone、notesはそれぞれ約10のNULL値を持ち、first_name、last_name、department、hire_dateは常に値を持ちます。

なぜ10%のNULL率か？

10%のNULL率は実用的な中間点です：

• NULLが少なすぎる（1〜2%）と、欠損データに関連するUIバグがほとんど表面化しない
• NULLが多すぎる（50%以上）とデータセットが非現実的になる
• **10%**はすべての重要なデータセットでNULLが出現しながら、ほとんどの行が完全であることを保証

決してNULLにならないカラム

宣言された制約に関わらず、以下のカラムはNULLを受け取りません：

• プライマリキーカラム
• オートインクリメント / SERIALカラム
• 明示的にNOT NULLとマークされたカラム

NULL処理のテスト

NULLシードデータにより以下を検証できます：

• テーブルでUIが空セルをどのようにレンダリングするか
• 検索クエリがNULLを正しく処理するか（IS NULL vs = ''）
• 欠損フィールドを持つレコードを編集する際のフォームプリポピュレーション
• null vs missing vs 空文字列のAPIシリアライゼーション