やる気がストロングZERO

やる気のストロングスタイル

扱いやすいテーブル・扱いにくいテーブル

システムのDBには様々なテーブルが定義されている。
色々作業していると「扱いやすいテーブル」「扱いづらいテーブル」がある事に気がつく。

なんとなく見えてきたパターンについて書いてみる。

※もしかしたら当たり前の知識なのかもしれないが、自分の観測範囲ではあまり話題にならないし、前提知識として認識されているようには感じていない。もし体系化されたわかりやすいものがあるなら知りたい。

参考)

リレーショナルテーブル

集合とリレーショナルモデルの考え方に沿った内容のテーブル。
参考本の「理論から学ぶデータベース実践入門」を読んで初めて認識できた。
データベースはこの考え方に沿ったプロダクトなので、これに沿って設計されれば無理のない、扱いやすいテーブルになる。

実際のテーブル設計ではテーブル定義の自由度が高くて「集合とリレーショナルモデル」の理論から逸脱したテーブル定義もできてしまうので、そういうテーブルは扱いづらいテーブルになりやすい。

マスターテーブル

マスターデータを保持するテーブル。
リレーショナルテーブルと言える。扱いやすい。

トランザクションテーブル

手続きの記録テーブル。購入履歴とか、発送履歴とかそんなやつ。
これもリレーショナルテーブルと言える。扱いやすい。
注意点として、ここに記録されるデータ(商品購入価格とか発送先住所とか)はマスターテーブルのデータからのコピーにする。
そうしないと、商品価格が変わった時や登録住所が変わった時に、事実と記録にズレが出てしまう。
ただし、マスターテーブルが以下に説明する「履歴テーブル」になっている場合は過去データを特定できるためデータコピーは不要。

履歴テーブル

過去状態や未来状態を持ったテーブル。特定期間ごとの商品価格が定義されているようなやつ。
リレーショナルテーブルではない。扱いづらい。
上記例の場合、特定商品に対しての金額がDB上では一意に決まらない。アプリケーション側からの支援が必要になりロジックが複雑化する。(日付を渡して特定の価格を引っ張る関数などの実装が必要になる)
リアルタイムで適用価格を切り替えたい場合等は履歴テーブルで扱うしかないが、多少のズレが許容される場合は価格テーブルには現在の価格だけ保持させ、別途履歴テーブルへ退避させるバッチ処理を使うことでリレーショナルテーブルとして扱う事が可能。
これも参考本の「理論から学ぶデータベース実践入門」に記載がある。

状態を持ったテーブル

削除フラグや処理状態(未着手 => 処理中 => 完了)を持ったテーブル。
リレーショナルテーブルではない。扱いづらい。

これが親テーブルになったりするとクエリもアプリケーション処理も複雑化する。絶対に避けたい。
参考本の「失敗から学ぶRDBの正しい歩き方」に記載がある。