関心ごとの分離

テーブル設計について現在勉強してます！今日は学習していて気がついた点を書いていこうと思います。

big table

みなさんは業務にあたっていてこんなテーブルに出会ったことはあるでしょうか？ userテーブルで一般userと法人userが同じテーブルに表現されている。法人番号カラムを持っていて、要件として一般userは法人番号を保持しない。ほんとは、法人番号カラムはnot null制約をかけたいが、一般userは法人番号を持たないという制約でnullableにせざるおえない。一般userと法人userを識別するフラグカラムまたは、Idに特定の文字列を入れてuserの判別を行う。(法人→AD、一般->GE) これらの例だけではなく、様々なカラムが含まれ肥大化したuserテーブルを僕は扱ったことがあります。このテーブルを見た時に僕は何が一般userに必要なデータなのか考えました。またそれはソースコードにも影響を与えコードを読む時間も増えました。ここまでで、適切に正規化ができていなのでは？？と考えられますし、その通りだと思います。ですが感じなことはuserという抽象的概念をちゃんと咀嚼して適切に概念整理ができていますか？というところに立ち返りました。

概念整理と関心ごとの分離

ここまで概念整理が適切にできていないと考えられました。適切に考えると法人userと一般userは概念が違います。なので適切な粒度としてリソース単位で分離することで、関心ごとの分離も行えます。また適切な粒度で分離することでnullのデータが減ります。そしてこれはclassの設計にも言えることですが、１つのclassでいろんなことをやらない、に精通しています。脱神テーブル！！

終わりに

一つのテーブルでいろいろ表現しようとしない。神テーブルを作らない。
複数の物事が表現されそうになったら、隠れた概念が存在するのかを考える
適切にリソースにテーブルを分けるように設計する