テーブル設計について考えてみる

mysql DB テーブル設計について考えてたのでメモ

■やりたいこと

・商品をもつ

・商品はユーザがみているデバイス（PC、スマホ、フューチャーフォン）にって表示・非表示などをきりかえる

・さらにCMSぽく？したいので同じプログラムで３サービス別々の商品にきりかえる

・mysqlつかう

 

商品数＝３０万件

サービス種＝３種（サービス１〜３）

デバイス種＝３種（PC、スマホ、フューチャーフォン）

 

■案１

・商品テーブル

商品ID(PK)

商品名とか

 

・商品出し分けテーブル

商品ID(FK)

サービスID(サービス1、サービス２、サービス３とか)

デバイスID(PC、スマホ、フューチャーフォンとか)

販売開始日とか

 

この場合のレコード数は３０万*3*3でマックス２７０万レコードが必要。。。

 

■案２

・商品テーブル

商品ID(PK)

商品名とか

 

・商品出し分けテーブル

商品ID(FK)

サービス1のPC用販売開始日とか

サービス1のスマホ用販売開始日とか

サービス1のフューチャーフォン用販売開始日とか

サービス2のPC用販売開始日とか

サービス2のスマホ用販売開始日とか

サービス2のフューチャーフォン用販売開始日とか

サービス3のPC用販売開始日とか

サービス3のスマホ用販売開始日とか

サービス3のフューチャーフォン用販売開始日とか

 

この場合のレコード数はマックス３０万レコード

けどサービス増やしたり、レコードふやすたびにカラム追加。。。

 

■案３

商品テーブル

商品ID(PK)

商品名とか

 

・商品出し分けテーブル（サービスごとに別データベースにする）

商品ID(FK)

デバイスID(PC、スマホ、フューチャーフォンとか)

販売開始日とか

 

案２は難しいかな。。。

 

個人的には案３なんだよなー。

サービスごとに異なる部分だけ別DBにして、共通な部分は共通DB的な。ジョインとかもきにしなくてはならなくなるはなるのだけど。。。

 

案１が一般的？な気がしないでもないけど、テーブルの種類も増えるとレコード数も増える。のでクエリのチューニングも必要になってきそうだし。。。

 

まーやりたいことしだいなのだけど。