テーブルの設計がどうしたらいいかわかりません

ジャニーズの情報をまとめたWikiみたいなWebアプリを作っています。
ページのデータをデータベースに保存しようとしていて、現在以下のようなテーブルを考えています。

TOP - TOPページの情報を入れています。
profile - グループ個人のデータを入れています。
TV - TVごとの情報を入れています
movie - 映画ごとの情報を入れています。
radio - ラジオごとの情報を入れています。
CM - CMごとの情報を入れています。
magazine - 雑誌ごとの情報を入れています。

それぞれに以下のようなカラムがあります。

artist -パラメーターで使う名前です。
group - 画面にのせるグループ名です。
name - 個人の名前やTVのタイトルなどを入れます。
setumei - 内容を入れています。

このような設計でどうでしょうか?

TOPページは編集させないことにし等と思うのでテーブル管理はしないことにします。
グループごとに以下のようなページがあります。

TOPページ - グループの説明を入れます。
profileページ - グループ個人のプロフィールを人数分入れます。
mediaページ - グループのメンバーのTV,movie,radio,CM,magazineの情報を入れます。

行動規範の内容に同意します

回答4件

ベストアンサー

面白そうなテーマでしたので、私なりに設計してみました。

ただし、これはあくまでご提示いただいた情報から推測した
「私ならこうするだろう」
というものであって、質問者様が想定されているWEBアプリに即したものかどうかは保障いたしかねます。

採用するとしても、適宜カスタマイズするか、
お近くに先輩エンジニアなどがいらっしゃれば、レビューしていただくのが良いと思います。

あと、個人的に"artists=グループ名"がどうしても納得できなかったので、
artistという言葉を（個人の）アーティスト、と言う意味で使用しています(^^;

見本

table1 : テーブル1
  column1 : カラム1
  column2 : カラム2
  ...
  * key1 : 複合キーなど
  ...

table1.column1の外部キー … table1テーブルのcolumn1カラムの外部キー

ジャニーズWikiアプリテーブル設計

groups : グループの情報を管理するテーブル
  group_id : プライマリキー
  group_name : グループ名
  description : 説明文

artists: アーティストの情報を管理するテーブル
  artist_id : プライマリキー
  artist_name : アーティスト名
  description : 説明文（生年月日・出身地などを細かく管理したければ、別途カラムを用意する）

group_artist_relations : アーティストが、どのグループに所属しているかを管理するテーブル
  group_id : groups.group_id の外部キー
  artist_id : artists.artist_idの外部キー
  * pk_group_artist_relations : group_idとartist_idの複合プライマリキー

media : テレビ・映画などの出演媒体を管理するテーブル
  media_id : プライマリキー
  title : タイトル
  genre : 媒体のジャンル。テレビ=1, 映画=2, ラジオ=3, ...
  description : 説明文

media_artist_relations : アーティストが、どの媒体に出演しているかを管理するテーブル
  media_id : media.media_idの外部キー
  artist_id : artists.artist_idの外部キー
  * pk_media_artist_relations : media_idとartist_idの複合プライマリキー

補足

group_artist_relationsテーブルについて

ジャニーズについてはよく知りませんが、一人のアーティストが複数のグループに所属することがありえると考えたため、n対mのリレーションを表現できるよう、group_artist_relationsテーブルを定義しました。
一人のアーティストは一つのグループにしか所属しないのであれば、artistsテーブルにgroup_idカラムを設けてもよいでしょう。

mediaテーブルについて

ジャンルごとに異なる情報を管理したい場合、
（例えばTVはテレビ局と放送時間、映画は配給会社と公開日、・・・など）
私なら

tv_additional_info : TVの追加情報を格納するテーブル
  media_id : media.media_idの外部キー
  broadcaster : 放送局
  ...

movie_additional_info : 映画の追加情報を格納するテーブル
  media_id : media.media_idの外部キー
  ...

...

のような感じで各ジャンルの追加情報テーブルを定義しますが、、
アプリ側の実装の難易度が高くなると思われるので、
そこまでやる必要があるのか、慎重に検討することをお勧めします。

アプリからのデータ読み出しについて

/TOP.jsp?artist=グループ名

というURLを想定してるようですが、これはまずい設計です。

もし、グループが改名したらどうしますか？
また、関ジャニ∞の"∞"をURLに含めて、アプリが正しく読み取れると確信できますか?

このような場合、各レコードに不変で一意な値（IDのことです）を割り振り、それを使用して

/TOP.jsp?group=[group_id]

と、やるのがよいでしょう。
もちろん、IDは数字（最悪でも英数字）です。

用語について

当回答には、質問者様がご存じない言葉が使われているかもしれません。
しかし、私は努めて一般的な用語を使用しているつもりですので、がんばって調べてみてください。

投稿2015/10/19 17:39

編集2015/10/19 17:54

KiyoshiMotoki

総合スコア4791

退会済みユーザー

2015/10/19 17:49

自分ならさらに、group_artist_relations に加入日・脱退日を持たせるかな。

KiyoshiMotoki

2015/10/20 02:57

Kosuke_Shibuya様、コメントありがとうございます。ご提案いただいた設計を加えると、例えば加入日・脱退日で検索やソートなどもできるようになりますね。ただ、今のところ、私は「そこはアプリの要件しだい」という立場を取らせていただきますw ご提案の設計だと同じグループへの"加入 -> 脱退 -> 再加入"を表現できなかったり、あるアーティストが所属中のグループを検索するために"脱退日 IS NULL"という条件を加えなければならないなど、メリットだけではない側面もあるためです。

退会済みユーザー

2015/10/24 14:46

詳しくありがとうございます参考にさせていただきます

行動規範の内容に同意します

・TOPは要らないと思います。静的コンテンツ（タイトルなど）はWEBアプリで実装する話でしょうし、動的なものは、TV, movie, radio, CM, magazineと同列にother（その他）として管理したほうが良いです。
・TV, movie, radio, CM, magazineは全部で１テーブルにまとめたほうが良いです。管理の仕方は、TV, movie, radio, CM, magazineの列を追加して、1or0のフラグ管理が良いです。こうすることで、重複情報を扱いやすくなります。
・列名に「group」は避けたほうが良いです。扱いづらくなる可能性があります。
・profileとTVのひも付けがイメージできません。ただ、管理かなり面倒になるんじゃないかと思いますので、思い切ってprofileは削除してみては如何でしょうか。
・掲載フラグの列を追加してやると、下書き的情報を管理しやすくなります。

投稿2015/10/18 20:52

TetsujiMiwa

総合スコア1124

退会済みユーザー

2015/10/19 13:30

profileで一つのページでTV,movie,,radio,cm,magazineで一つのページです。

退会済みユーザー

2015/10/19 13:31

1or0フラグの管理とは何ですか?

TetsujiMiwa

2015/10/19 13:37

データパターンが1か0という管理方法です。

退会済みユーザー

2015/10/19 14:00

すみません、何を1or0で管理するのかわかりません

TetsujiMiwa

2015/10/19 14:05

記載の通りの列です。

行動規範の内容に同意します

どのような目的でDBを使うかによるかなぁと思います。
ただ、運用がしやすいようなデータストラクチャだといいですね。

列挙されたテーブルを大きく分けると、
・TOPページ
・コンテンツ (TV, movie, radio, CM, magazine)
・入力値チェック用の情報 (artist, group, name, setumei?)

という感じでしょうか？

最もメインになるコンテンツ部分のデータストラクチャは一定にして、
アプリ側のインターフェースを簡単にするのはどうですか？
(例) -> 記事ID、タグ、タイトル、本文、作成日時、更新日時

TOPページはContentsから更新日時が近いものを列挙していく感じでしょうか。
インターフェースの構築が容易な形で
(例) -> 最終更新日時、最近の更新内容1、最近の更新内容2、最近の更新内容3

入力値チェック用の情報はアプリ側からコンテンツテーブルにinsertを行う時の
バリデーションに使うだけかと思うので、あっても無くてもいいんじゃないかなぁって思います。

という感じでしょうか？

投稿2015/10/18 15:48

SKYYFISH

総合スコア654

退会済みユーザー

2015/10/19 13:37

更新日時を記録することはありません。

行動規範の内容に同意します

この情報だけでは適切な設計か判断できません．
たとえば，データベースとのやり取りを極力減らしたい場合(古い携帯端末などスペックが低い場合など)は，管理はしづらいですが，すべてを1つのテーブルにまとめ，1度で必要な情報すべてを取れるようにします．

ある程度の人数で管理し，データベースに厳密な設計が求められる場合は，データベースの正規化などについて検討する必要があるでしょう．

個人的に作成する場合には，自分で管理しやすければ十分でしょう．他人にこの形が正規化されていて完全なテーブルだって言われたものを管理するより，ずっと長く続けられると思います．

いくつか指摘すると，TOPページの情報をデータベースで管理するということがいまいちピンときません．
TOPページをデータベースの中身から生成するのでしょうか．
また「artist -パラメーターで使う名前です。」には複数の値が入ることが予想されますが，複数の値を同じフィールドに持たせることは，データベース正規化の点からみると適切ではありません．別テーブルに分けるべきでしょう．

投稿2015/10/18 15:41

退会済みユーザー

総合スコア0