人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

趣味で映画レビューサイトを構築中です。
その下準備として映画データベースを作ろうとしているのですが、テーブル構成で悩んでいます。
わたしが考えたデータベース内のテーブル構成は以下になります。

?映画情報テーブル
タイトル、製作年、製作国、ジャンル1、ジャンル2、ジャンル3、監督、出演者1、出演者2、出演者3、出演者4、出演者5、あらすじ

?レビューテーブル
タイトルid、感想、点数、印象(泣ける、笑える等)、見る相手(家族と、恋人等)

?付録テーブル
タイトルid、画像1、画像2、画像3、動画

はじめて、大規模なデータベースを作るので勝手が全く分かりません。
このままのテーブル構成で大丈夫なのかとても不安です。
(掲示板なら大丈夫なんですが・・・)
みなさんならどのようなテーブル構成にしますか?
あとその際に心がけていることを教えてください。
よろしくお願いします!

●質問者: ぱんたま
●カテゴリ:インターネット ウェブ制作
○ 状態 :終了
└ 回答数 : 3/3件

▽最新の回答へ

1 ● うぃんど
●100ポイント ベストアンサー

運営形態や運営規模、開発言語などにもよりますが、

質問文にある情報を管理すると決めたならば、

下記のように、ある程度正規化したものをたたき台として、

データの取り扱い易さ/プログラミングの容易さなどを絡め、

必要な構成に煮詰めていきます

(1)マスターテーブル群

■ジャンルマスターテーブル

ジャンルID、名称

■人物マスターテーブル

人物ID、氏名、監督フラグ、

脚本家フラグ、出演者フラグ、

メモ(出身地とか、血液型とか・・・)

※監督フラグなどの種類が多くなる場合は別テーブルにする

■国名マスターテーブル

国ID、国名

※これはデータ入力補助のために用意しておくもの

メンテナンスを考えるとプログラムに記述しておくより楽だけど、

処理速度を求めるならばプログラムに記述しておくのも手

(2)データテーブル群

■映画情報テーブル

タイトルID、タイトル、製作年、製作国、監督(人物ID)、脚本(人物ID)、あらすじ

■ジャンルテーブル

ジャンルID、映画ID

■出演テーブル

人物ID、映画ID

■レビューテーブル

タイトルID、感想、点数、印象(泣ける、笑える等)、見る相手(家族と、恋人等)

■付録テーブル

タイトルID、通し番号、タイプ(画像か動画かなど)、リンク


うぃんどさんのコメント
監督や脚本などが複数人になったり、 監督本人が出演してたりなんてことを考えると、 下記のほうがいいかも・・・ ■映画情報テーブル タイトルID、タイトル、製作年、製作国、あらすじ ■(出演者テーブル改め)関係者テーブル 人物ID、映画ID、出演者、主演フラグ、監督フラグ、脚本家フラグ こうやって煮詰めていきます(苦笑)

ぱんたまさんのコメント
このようなたくさんのテーブルを作ってしまうと、データを追加(insert)する際にとても難しく感じます。 人物マスターテーブルに関しては、あらかじめたくさんの人物をいれておいたほうがいいのでしょうか? 作品を追加するごとに、人物を追加していくのではなく。

うぃんどさんのコメント
>データを追加(insert)する際にとても難しく感じます php+MySQLの組み合わせでは、 ”一度に複数のSQL文を送れない”ので若干面倒ではありますが、 SQLを順に送るようなサブルーチンを作っておけば良いだけです 1.START TRANSACTION(トランザクション開始宣言) 2.SQLを順に送って実行 3.エラーがあればROLLBACK(改変を無かったことに)して抜ける 4.SQLがまだあれば2へ、すべて終わればCOMMIT(作業終了処理) http://dev.mysql.com/doc/refman/5.1/ja/transactional-commands.html >あらかじめたくさんの人物をいれておいたほうがいいのでしょうか? あらかじめ入れることが可能であれば、入れておいたほうがいいでしょうね そのためには人物マスターテーブルだけを入力しやすくするようなページを 用意するということになるわけですが、、、 それがマスターメンテナンス画面などと呼ばれているものです 通常の操作から入力する方法と管理者が直接テーブルを操作する方法の、 二種類を用意しておくということです

ぱんたまさんのコメント
>php+MySQLの組み合わせでは あまり詳しくはないのですが、サブルーチンはMySQ上ではなく、php上で作るんでしょうか? あと ■人物マスターテーブル の監督フラグの「フラグ」は何を指しているのでしょうか?

うぃんどさんのコメント
>サブルーチンはMySQ上ではなく、php上で作るんでしょうか? MySQL上(ストアドプロシージャ)にしても良いですが、 理解しやすさからphp側で組むことをとりあえず回答しました >フラグ その人が監督経験ありならば真、なければ偽 同様に脚本家経験ありならば真、なければ偽 同様に出演経験ありならば・・・ これらのフラグによって、監督一覧表などが簡単に作れるようになり、 監督選択プルダウンメニューなども楽に作れるということになります (操作性の面から煮詰めた成果物の一例ということです)

ぱんたまさんのコメント
フラグの意味を理解できました。 ありがとうございます!

ぱんたまさんのコメント
windofjulyさんが考える (出演者テーブル改め)関係者テーブルの入力の仕方は以下の方法で合ってますか? 人物ID, 映画ID, 出演者 1, 1 ,ブラッド・ピット 2 ,1, アンジェリーナ・ジョリー 3 ,1 ,モーガン・フリーマン 主演フラグ, 監督フラグ, 脚本家フラグ, 脚本家フラグ TURU, FALSE, FALSE, FALSE TURU, FALSE, FALSE, FALSE TURU, FALSE, FALSE, FALSE

うぃんどさんのコメント
関係者テーブルは、そんな感じで新しい映画を登録する度に、 監督や出演者などの関係者をひたすら追加していくという形です そして、関係者テーブルへの追加と合わせて、 人物マスターテーブルにも新規追加もしくは更新を行います なお、 出演者名は人物マスターテーブルのほうにあるので冗長ですが、 検索や閲覧時の負荷軽減のため関係者テーブルにも入れてます

ぱんたまさんのコメント
windofjulyさんが考えるテーブル構成が、少しずつ分かって来ました。 そうなると、 「印象」や「見る相手」もジャンルのように固定なので、 ジャンルマスターテーブル(ジャンルID、名称)、ジャンルテーブル(ジャンルID、映画ID)のようにしたほうがよさそうです。 印象マスターテーブル(印象ID、名称)、印象テーブル(印象ID、映画ID) 見る相手マスターテーブル(見る相手ID、名称)、印象テーブル(見る相手ID、映画ID)

うぃんどさんのコメント
>「印象」や「見る相手」もジャンルのように固定 手入力を想像していたのですが、システム側で固定するなら、 マスターテーブルにしてしまうのは一つの手ですね だいたい揃ってきたようなので、次に行う事として、 テーブルと適当なデータを用意しつつ、 下記それぞれに必要なSQL文を書き、 まずはphpを使わずMySQLのテーブルを直接操作し、 phpMyAdminなどでデータがどうなったかを確認していきましょう 1.データ追加時に行う処理手順と、実行に必要なSQL文 2.データ照会時に行う処理手順と、実行に必要なSQL文 3.データ削除時に行う処理手順と、実行に必要なSQL文 4.データ更新時に行う処理手順と、実行に必要なSQL文 SQLの確認が出来たら、HTMLフォームから受けとったデータを、 MySQLに送り込むようにHTML+phpでインターフェースを作る・・・ 出来ればですが、適当にデータをコピーして増やしたものを用意して、 パフォーマンスチェックもしたいところです 複数のテーブルを使うことでパフォーマンスが問題になるようであれば、 「ジャンル」や「印象」や「見る相手」といった容量の少ないデータを、 phpの中にコードとして埋め込んでしまうというような手もありますが、 それはまた別の話ということで・・・ とりあえず、こんなところ?

ぱんたまさんのコメント
ここまで、具体的な案をだしていただき本当にありがとうございます。

ぱんたまさんのコメント
>「ジャンル」や「印象」や「見る相手」といった容量の少ないデータを、 phpの中にコードとして埋め込んでしまうというのは、 それらのマスターテーブルを作らないってことなのでしょうか? 例えば、映画情報テーブルに「ジャンル1」「ジャンル2」「ジャンル3」カラムを追加。 レビューテーブルに「印象」「見る相手」カラムを追加。 ってことなのかな。 初心者のわたしには、管理がしやすいこの方法がいいのかなと思いましたけど・・・。

うぃんどさんのコメント
>マスターテーブルを作らないってことなのでしょうか? そうです MySQLに問い合わせてマスターテーブルから抜き出すのではなく、 phpの内部で番号にあった文字列を出力するというような形です >管理がしやすいこの方法 最初から書かなかったのは、管理が面倒な方法だからです システムのメンテナンスを続けて経験を積めば積むほど身にしみてきますよ データベースに書く →マスタメンテナンス画面でデータを替えるだけ 動作がおかしくなっても変更したデータを再度修正するだけ phpコード内に書く →セミコロンを忘れるといったような初歩的操作ミスから、 想定外のバグとなる可能性まで秘めている エラー発生箇所と原因箇所は必ずしも一致しないため、 初歩的記述ミスであっても、修正に時間を要する可能性大

ぱんたまさんのコメント
分かりやすいご返答ありがとうございます。 ジャンルマスターテーブルさえ作っておけば楽ですもんね。 後で変更を加えたい時はそのテーブルをいじるだけですみますし・・・。 ついでにお聞きしたいのですが、作品のデータを入力する処理に関してです。 一回で全てのデータを入力したほうがいいのでしょうか? それとも、 ?映画の情報テーブルを入力→?ジャンルテーブルを入力→?出演テーブルを入力。 というように、何回かのステップに分けて入力していった方がいいのでしょうか?

うぃんどさんのコメント
>何回かのステップに分けて入力 いいえ 途中で処理が止まったりしてカスが残っても面倒ですから一括が望ましいでしょう そのためのトランザクションです 今一度書いておきます 1.START TRANSACTION(トランザクション開始宣言) 2.INSERT INTO 映画情報テーブル 以下略 3.MySQLからエラーが帰ってくれば1.の時点の状態までデータを戻す(ROLLBACK) 2.INSERT INTO 出演テーブル 以下略 3.MySQLからエラーが帰ってくれば1.の時点の状態までデータを戻す(ROLLBACK) ・・・ 4.一通り全て正常に終わったらトランザクション終了(COMMIT)

ぱんたまさんのコメント
流れは分かりました。あとはやっていくだけです! すいません。少しお話が戻ってしまいますが >出演者名は人物マスターテーブルのほうにあるので冗長ですが、 検索や閲覧時の負荷軽減のため関係者テーブルにも入れてます という考え方でいけば、 ジャンルテーブルも(ジャンルID、映画ID、ジャンル名)にしたほうが良さそうですね。

ぱんたまさんのコメント
本当にありがとうございました!!

2 ● kodairabase
●100ポイント

注意点:マスタテーブルと情報テーブルを区別し、下記の基本情報テーブルを起点としたリレーショナル構造を組むことです。


  1. 基本情報テーブル
    • 映画ID(※重複不可)
    • 原題
    • 原題サブ
    • 邦題
    • 邦題サブ
    • 制作国ID(国名ID)
    • 監督(人名ID)
    • あらすじ
    • 登録年月日
    • 登録者ID(ユーザーID)
    • 更新年月日
    • 更新者ID(ユーザーID)
  2. メディア情報テーブル
    • 映画ID(※重複可)
    • ファイル名(静止画、動画、音声など)
    • 登録年月日
    • 登録者ID(ユーザーID)
    • 更新年月日
    • 更新者ID(ユーザーID)
  3. レビュー情報テーブル
    • 映画ID(※重複可)
    • 感想
    • 点数
    • 印象
    • 見る相手
    • 登録年月日
    • 登録者ID(ユーザーID)
    • 更新年月日
    • 更新者ID(ユーザーID)
  4. キーワード情報テーブル
    • 映画ID(※重複可)
    • キーワード名
    • 登録年月日
    • 登録者ID(ユーザーID)
    • 更新年月日
    • 更新者ID(ユーザーID)
  5. ジャンル情報テーブル
    • 映画ID(※重複可)
    • ジャンルID
    • 登録年月日
    • 登録者ID(ユーザーID)
    • 更新年月日
    • 更新者ID(ユーザーID)
  6. 出演者情報テーブル
    • 映画ID(※重複可)
    • 出演者(人名ID)
    • 登録年月日
    • 登録者ID(ユーザーID)
    • 更新年月日
    • 更新者ID(ユーザーID)
  7. 映画人名マスタ
    • 人名ID(※重複不可)
    • 人名
    • 登録年月日
    • 登録者ID(ユーザーID)
    • 更新年月日
    • 更新者ID(ユーザーID)
  8. ジャンルマスタ
    • ジャンルID(※重複不可)
    • ジャンル名
    • 登録年月日
    • 登録者ID(ユーザーID)
    • 更新年月日
    • 更新者ID(ユーザーID)
  9. 国名マスタ
    • 国名ID(※重複不可)
    • 国名
    • 登録年月日
    • 登録者ID(ユーザーID)
    • 更新年月日
    • 更新者ID(ユーザーID)
  10. ユーザーマスタ
    • ユーザーID(※重複不可)
    • ユーザー名
    • 登録年月日
    • 登録者ID(ユーザーID)
    • 更新年月日
    • 更新者ID(ユーザーID)

ぱんたまさんのコメント
マスターテーブル群には、あらかじめ人物(映画関係者全員)やジャンルをいれておくものなのでしょうか?

3 ● Cherenkov
●100ポイント

既存のシステムを手本にしたらいいんじゃないですか。

仕様を決められるのは製作者の特権。よく考えてダメだったら作りなおす。

関連質問

●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ