mike-neckのブログ

Java or Groovy or Swift or Golang

データベース設計についての、僕の知っていることをちょこっと(4)

こんにちわ、みけです。

しょぼちむにデータモデル設計について教えてくださいの会 #syoboben - connpass

例によって、適当にテーブル設計について言いたい放題言うシリーズ(?)第四弾です。

今日はヌルになるかもしれない項目について


非ヌル三原則

ヌルになるような項目は「持たず、作らず、持ち込ませず」が原則です。

T字型ER図手法の研修を受けた人からの伝聞では、佐藤正美さんという発案者の方がヌルになる可能性のある項目がテーブル内にあることについて、「出たな妖怪ヌルお化け」とか言ってたとかなんとか…

まあ、僕のブログを見るような物好きな人は、null嫌いでOptional<T>を使うのが当たり前の人ばかりですから、テーブルの中にもnullな項目を入れ込んだりしませんよね。

存在しないかも知れない項目

単純です。存在しないかもしれない項目は別のテーブルに分けます。

例えば、次のようなテーブル(バーチャルエンティティをまとめてるやつ)を考えます。

派遣登録者

カラム
登録者ID 数値
登録者氏名 文字列
登録者住所 文字列
コメント 文字列
登録日 日付

さて、このテーブル、人によってはコメントに何も登録しないことがあります。

こういう場合の一般的な対処は次のとおりです。

  • 空文字列を入れる
  • NULLにする

空文字列の方はよくありそうですが、開発者によっては勘違いして、NULLで入れてしまいそうですし、NULLで入っているものとしてなんらかのロジックを組んでしまうかもしれません。

ちなみに、例が貧弱なのは、特に思いつかなかったからです。

存在しないかもしれない項目を外部化する

いずれにせよ、存在しないかもしれない項目というのは扱いが面倒なのです。

if(comment == null)というボイラーコードを入れなくてはならないし、いや空文字列だろうと勘違いして、nullちぇっくしなくてヌルポ!(ΦωΦ)ガッとなったり。

そこで僕なら、存在しないかもしれない項目は別のテーブルに分離します。

先に上げた非ヌル三原則です。

テーブルの中にはヌルを持たない、作らない、持ち込ませない!

ヌルヌル

こんな感じでヌルを追い出しました。

必要だったら、登録者IDから引っ張ってこれるので、それほどパフォーマンス的にも問題ないかな(適当)


以上、間違いだらけのテーブル設計でした。議論が荒いのは、僕のうつ状態が酷いからであって、僕が悪い。

あと、ちなみに、登録者の氏名、住所、コメントが変わる可能性ありますが、そのへんは考慮していません。あしからず。