ジャンルごとにカラム数が増減する場合のテーブル設計について

Question

いろいろなジャンルの店舗を管理するシステムを作成しています。

ジャンルごとに共通のカラムも多いのですが、特有のカラムもあり、このような構造のテーブル設計をどうすればよいかご教示いただけますと幸いです。

現状では、opt1-opt10とフリーで入力いただけるカラムを用意しています。

■利用データベース
・MySQL

Answer 1

• ジャンルテーブル

ID
ジャンル名
全ジャンルに共通するカラムを必要な数だけ

• 個別データテーブル

ID
ジャンルID
ジャンル内での順番
データ名
データ

みたいな感じでテーブルを分割して、使用する時はジャンルテーブル.IDと個別データテーブル.ジャンルIDをJOINさせるのが典型的な設計かなと思います。

考え方としてはデータベース 正規化あたりをキーワードにして調べてみると良い資料が多くあります。（DB設計に関しては書籍を一冊しっかり読んでみるのをお勧めします）

Comments

[tkda]

ありがとうございます！まずは調べてみます。

Answer 2

「特有のカラム」での検索・集計などが一切不要であれば、extraのような列を作っておいて、そこにJSONなりでシリアル化したデータを入れておく、というような手段もあります。

Comments

[tkda]

そうですね。確かに質問がざっくりとしすぎていました。申し訳ないです。
検索、集計などは行います。

以下でも言及されていました。
https://qiita.com/ka215/items/a00eae000220bf872e28

>　一昔前のCRMなどのユーザー管理テーブルとかにありがちな、各クライアント別に拡張項目を自由に設定できるように、拡張用カラムを大量に用意してあるテーブル構造だと思ってもらいたい。
>　今時なテーブル設計であれば、拡張項目はキー・バリュー型のオプション・テーブルとしてリレーションさせるのが一般的だと思うが、こういうレガシーなテーブル構造を持っているWEBサービスは割と多い。

Answer 3

ジャンルごとに共通のカラムも多いのですが、特有のカラムもあり、このような構造のテーブル設計をどうすればよいか

エンティティの洗い出しと正規化を再度実施してみては？
普通は特有のカラムなんて作らなくて良いです。

ただ、なんらかの要件によって特有のカラムを作る設計にしているのであれば、その要件が無いと回答は出来ないんじゃないかなぁ。。。

Comments

[tkda]

ありがとうございます。特有のカラムという書き方が誤解を与えているのかもしれません。

以下でも言及されていました。
https://qiita.com/ka215/items/a00eae000220bf872e28

>　一昔前のCRMなどのユーザー管理テーブルとかにありがちな、各クライアント別に拡張項目を自由に設定できるように、拡張用カラムを大量に用意してあるテーブル構造だと思ってもらいたい。
>　今時なテーブル設計であれば、拡張項目はキー・バリュー型のオプション・テーブルとしてリレーションさせるのが一般的だと思うが、こういうレガシーなテーブル構造を持っているWEBサービスは割と多い。

[退会済みユーザー]

エンティティの洗い出しが正しく行えない場合に、拡張用のカラムを作成する要件が発生します。
洗い出しが不可能なのか？洗い出しの手法が間違っているのか？再度実施してみては？というのが回答です。

不可能である場合は、要件によって縛られているので、その要件を提示してください。

Answer 4

・共通カラムは1つのテーブルにまとめる
・ジャンル特有のカラムはジャンルごとにテーブルを分ける
・共通ののカラムのテーブルとジャンル特有のカラムのテーブルはJOINでつなぐ

詳細仕様がわからないため、この程度のことしか申し上げられませんが。。。

Comments

[tkda]

新規のジャンルが追加される毎にテーブルを作っていくような仕様なんですね。各ジャンルごとにカラムを増減させようとする度に、DBを変更しないといけないので、それなら、opt1-opt10まで固定で作っておいたほうが運用上うまく回せるかなと思うのですがいかがでしょうか。