DB設計をしていて継承っぽいテーブル設計にした方がスマートに実装出来そうな気がしたので、
継承した時のそうでない場合のメリットデメリットを考えてみた。
例) ソシャゲでありがちな課金アイテムとログインなどで獲得できる通常アイテム
普通に設計するならばcharge_items と normal_items テーブルがあります。
ただログインボーナス(1日目にこのアイテムあげる)みたいなテーブルを作ろうとした場合に
ログインボーナステーブルには、charge_item_id と normal_item_id を持たなければならなくて、
課金アイテムだけプレゼントする場合はnormal_item_idが0として登録される。
なんか気持ち悪い…もし、特別なアイテムが増えた場合にテーブルが増える可能性があり、
その場合にテーブル追加に加えて,ログインボーナステーブルにレコードを追加しなければならない。
ソースコードも大幅に変更する可能性が出てくる。
そんな時に継承っぽい設計にしたらどうだろうか。
charge_itemsとnormal_itemsにitem_masterへのリレーションがあり、login_bonusesには
item_master_idが紐づけられている。
なんか良い感じな気がする。
もし特別なアイテムが増えたとしてもテーブルを増やすだけで、他のテーブルには影響しなさそうだ。
ここいらでメリットデメリットを考えてみました。
前者
メリット
- itemテーブルにレコードを追加する時は追加テーブルだけで意識すれば良い
- 参照時も同じく一つのテーブルで完結する
デメリット
- 先述したようなテーブル構成だとDBに縛られた運用しか出来なくなる可能性がある
- id列に0が入るってなんかきもい…
後者
メリット
- テーブル追加時に影響が少ない
- なんとなくきれい
デメリット
- charge_itemsテーブルにレコード追加するときはmaster_itemsにもレコードを追加しなければならない
- 外部キーにindexを張るとしたらレコード追加時のコストが増加する
結論
参照が多い場合は後者、追加更新が頻繁にあるようなシステムであれば前者を適用するのが良いんですかね〜。
この辺のベストプラクティスみたいなのご存知の方いらっしゃいましたらご教示ください。
追記
railsであればポリモーフィックという継承ちっくな実装を提供しているということでこれを使えば良さげですね。
http://shirusu-ni-tarazu.hatenablog.jp/entry/2012/11/04/173742