DBのnot null指定について考えてみた

DB設計をしながらnullの諸悪の根源説について考えた事です。

以前にも同じような事を考えていた時は、smartyを最大限利用するため、DBのデフォルトにnullを入れることを推奨する結論に至った。
smartyで変数の出力時に指定したデフォルト値が出力されるには、値が空欄かnull、もしくは変数そのものが設定されていない状態である必要があるからである。
DBから取得したデータをそのまま配列化して渡すと、DBでnullの代わりにdefaultに「0」を指定していたりすると、smartyは値が「0」でも空欄とは判別してくれない。よって、default値を表示してくれない。
その為、基本的に空欄が許される値はすべてdefaultにnullを指定した。

改めて違う視点から考えてみると、どう考えてもnullは悪だ。
その前提で、null撲滅路線で考え直したところ、新たな結論が生まれた。

以前は深く考えなかったが、カラムのdefaultでnot nullを指定した場合、numericやdate系の固定長カラムでは空欄の入力は許されないが、character系の可変長カラムでは問題無く空欄の入力が行える。
"varchar = ''"と言った感じでOK。
numericやdate系のカラムの場合に空欄を入力できない問題については、頭の中で考えたら頭が爆発しそうだったので、いくつかの既存のデータベースとテンプレートのロジックを確認して、nullが「0」に変わることで問題になる可能性を探った。
結論から言うと、問題なし。正確にはnullを「0」に置換した場合は、さすがに若干の問題はあるが、初めからnullではなく「0」を想定して構築するならば、まったく問題にならない。
numericカラムにdefault値を入れる事なんて、「0」以外まずない。
dateなら、unixtimestampの「0」という値は空欄ではなく1970年1月1日である。
datetime型を使うなら、defaultを最小の日付にでもしておけばよい。now()でもよいかも。この日付が表示されて問題になることは想定できない。また検索対象になることが想定されないならば、characterで指定して、defaultにunknowとでも入れても問題はないだろう。
過去の経験からも、理論的にもnumericやdateのdefault値は「0」で固定してしまって問題ないので、今後はこの方針で設計していこう。

※ちなみに、mysqlのデータ型でchar型は指定された長さに固定されます。固定長カラムです。
また、VARCHAR 型のカラムの値は可変長の文字列になります。登録された値によって、カラムのデータ容量が増減します。
「character系の可変長カラム」と書いたが、これはchar型の固定長カラムでも空欄の入力が可能。