DB設計のときステータスの表現

なんか昨日から鼻から上顎、喉にかけてが痛い。保育園で夏風邪が流行っているし長男も次男もこの前鼻水垂らしていたから移ったかな・・・。妻も同じような感じで体調悪いらしい。 新型コロナも流行っているしちょっと気をつけないといけない。

昨日、今日と仕事をしつつ色々とDBのテーブル設計について考えているのだが、RDBにおいてデータを正規化する時、

  1. エンティティから状態を切り出す
  2. エンティティからリストで保持されている情報を別テーブルに切り出す

の2つをいつもやっていて、これ以外は特にテーブルをどうこうすることはしていない気がする。というかしていない。

エンティティから状態を切り離すときって色んな切り離し方があって、次のような種類がある。

  1. フラグ(Booleanで表されるやつ)
  2. ステータス(カラムに数字とかで表現されるやつ)
    1. 1つのエンティティ内で完結するもの
    2. 2つ以上のエンティティが関係するもの

このうち『フラグ』『ステータス(1つのエンティティ内で完結するもの)』については、エンティティを表現するテーブルから枝葉のようにテーブルを生やして(個人的にフラグテーブルと呼んでいる)管理する。このテーブルの使用方法は基本的にはフラグと同じでレコードがあれば「True」、なければ「False」を表現するものとして扱う。なので外部キーに対してユニークキー制約を必ず設ける。

ステータスが2値の場合はフラグテーブルは1つ、値が3つ以上の場合は各ステータスごとにテーブルを作成するようにしている。

『ステータス(2つ以上のエンティティが関係するもの)』については、関連テーブルでステータスを表現する。ステータスの表現としてはこのパターンが一番面倒かもしれない。理由は、永続的な状態を表すものと、一時的な状態を表すものの2つがあって、前者は複数の外部キーで複合ユニークキー制約を貼ればいいが、後者は条件によって重複を許すような形になるからここの仕分けがちょっと面倒だなぁと思う。

この、条件によって重複を許すような関連テーブルをステータスと言う意外に何かいい言い方というか概念はないかと常々思っている。こういうのは実は考え方というか概念一つでかなりスマートに捉えられると思うのでここに関しては考え続けたいと思った。

まぁ、色々考えたけどこういう思考を日々続けていくことが重要だなぁと思うのでちょくちょく日記として書いていきたいな・・・とりあえず仕事するか。

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください