🔥
[DB設計]nullableカラムって何が悪いの？良いnullと悪いnullがある？
背景
とあるテーブルがさまざまな用途に使われていて、意図しないデータも登録されているような状態でした。
そのテーブルには無数のnullableカラムが...！(またかよ)
今回そのテーブルに改修を加えることになったのですが、「なぜ今の状態ではダメなのですか？ユーザー的には特に問題は起きていないのですが😕」といった反応をいただきました。
改めて、なぜnullableカラムってだめなの？なぜ工数膨らんででもDB改修をしないといけないの？をきちんと説明できるようにするために本記事を作成しました
本記事にあるnullの弊害はあくまで実体験でのお話です！書いてある内容に限らずですので悪しからず〜
nullableカラムによる弊害
以下に限らずですが
- アプリケーションでnull考慮が必要
- 例：
$hoge < 3とかしたときにnullだとtrueになってしまう(本来は値が入っていないのでtrueとして扱いたくない)これはPHPだけの仕様かもだけど
- 例：
- クエリの条件が増えることがある
-
where hoge_column is not nullの条件が必要になったり...
-
- DBを見ただけだと異常値なのか正常値なのかの判断ができない
避けたいnullable
以下に限らずですが
- 用途はまだ未定だが使うかもしれないから追加したカラム(とりあえずnullで入れておく)
- 必要になってから、その要件にあったカラムを追加する方が良い
- いざ必要になった際にカラムの要件が変わっている可能性もあるため
- 本来の使われ方とは異なる使われ方をされる可能性があるため
- 必要になってから、その要件にあったカラムを追加する方が良い
- 条件によってnullableかどうかが異なる場合
- 例えばhogeカラムが1の場合はnull不可だが2の場合はnullでないといけない、のような
- nullかどうかでデータの振る舞いが変わる場合
- 顧客IDカラムがnullでない場合は顧客に紐づくデータ、商品IDカラムがnullでない場合は商品に紐づくデータ、のような
- 今回改修対象のテーブルはこのパターンのカラムも含んでいました！
- そのせいでさまざまなテーブルと紐づいており、データ件数はすごい数に...
- 様々なテーブルに紐づくと、改修の際の影響範囲も無駄に広くなって大変ですよね
nullの分類
こちらにわかりやすい図がありましたので拝借いたします
nullableカラムを追加する際、そのカラムになぜnullが必要なのかを一度立ち止まって考えた方が良さそうだ
感想
なんだこのテーブルは。。。と思うこともあるけども
その分勉強になるのでそれもまた良きと思いました
参照
Discussion