テーブルの抽象化

背景

DB設計を業務で行なっていたので、気になった部分をメモしました。

DB設計の抽象化

DB設計をしていると、細かい部分は異なるけれども、共通する部分を持っているデータが出てくることがあります。
例えば、ある物販システムが扱う商品に、「食品」「衣料」「書籍」という区分があったとして、それぞれが次のようなデータ構造を持つとします。

プログラミングでは共通部分はまとめて継承という形で個別なものを作っていきます。しかしDB設計では必ずしもそれが正解とは限りません。それを今回まとめていきます。

パターン１：テーブルを具体的にする

最初に紹介するのは、抽象化などは一切考慮せず、各種の商品タイプごとに必要な属性をすべて列挙するという愚直なやり方。

どういう状況で使われるのか：テーブルが増えない時など拡張性がない場合に使われる。
メリット：構造がシンプルで複雑化しにくい、テーブル構造をすぐに理解することができる。
デメリット：共通属性の追加や変更, 削除が発生した場合、すべてのテーブルに対して変更を実行しなければならない。

パターン２：1つのテーブルでデータを管理する。

次に紹介するのは、1つのテーブルですべてのデータを管理するやり方です。

どういう状況で使われるのか：運用していく上で拡張をしていく場合
メリット：機能を追加する時に絡むだけを追加すればいいので、テーブルを追加する必要がない
デメリット：カラムが増えすぎるとテーブルが見にくくなってしまう。

パターン３：共通部分を分離して管理

共通化の部分を切り離したやり方です。

どういう状況で使われるのか：共通している部分のカラム数が多い時に使われる。
メリット：データを安全、確実に管理することができる。データを高速に扱うことができる。
デメリット：カラムが増えすぎるとテーブルが見にくくなってしまう。

所感

どのパターンがいいか悪いかではなくケースバイケースでどれも採用される。