質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.35%

MYSQLを使用した口コミ・商品テーブルの設計について

受付中

回答 3

投稿 編集

  • 評価
  • クリップ 0
  • VIEW 801

ganbarunba

score 6

前提・実現したいこと

PHP+MYSQLでkakaku.comのようなユーザー登録機能+各商品の口コミ機能+各商品のまとめ記事投稿機能をつけたものを構築したいのですが、PHP+MYSQL共に独学で小規模利用しか経験がありません。
大規模化になる事を想定してテーブルを設計しようとする場合、どのように設計すれば、データ数が増えても処理がもたつかず、将来の拡張等にも対応しやすいのかが良くわかりません。
大体以下のように考えているのですが、過不足やアドバイス等、何かありましたらアドバイスやご指摘等いただけると大変助かります。
なお、今回のシステムは初級レベルの個人でやるのですが、可能な限り大規模システムの経験者の方々の貴重な意見等を取り入れて、長く使えるシステムにしたいと考えています。
丸投げではなく、プログラミングやデータベースを独学で勉強して試行錯誤しながらやってきた素人で技術レベルの低い人間ではありますが、経験者の方々の貴重な意見を取り入れて可能な限り長く使える良いデータベースを設計してみたいとの意図で書き込みをさせていただきました。
プロの方たちには不適切な質問、気に入らない丸投げ質問に見えてしまったようであれば申し訳ありません。
(今回、teratailを使って質問するのもはじめてで勝手がよくわからないのですが、初心者はこのような扱いをされてしまうのでしょうか?)
何卒よろしくお願いいたします。

(最大想定ユーザー数)
ユーザー数 最大:10万人(MYSQLを利用して一定時間以内で検索(0.5秒以内)、登録(1秒以内)できる事が前提)

(現在考えている大まかなテーブル設計-最低限の事項のみ掲載)
(1)t_user[InnoDB] ユーザーテーブル (最大データ数100万件を想定)
user_id(autoincrement),mail_adress(メールアドレス),username(ニックネーム),password(パスワード),regdate(登録日)
※user_idがプライマリキー

(2)t_product[InnoDB] 商品テーブル(最大データ数100万件を想定)
pro_id(autoincrement),pro_name(商品名),pro_cat(商品カテゴリーID),pro_data1(商品基本データ1),~pro_datan(商品基本データn)、regdate(登録日)、update_date(更新日)
※pro_idがプライマリキー

(3)t_kuchikomi[InnoDB]口コミテーブル(商品カテゴリID別に必要数のテーブルを作成:1テーブル辺りの最大データ数約1000万件を想定) 
kuchikomi_id(autoincrement),user_id,pro_id,kuchikomi_id2(口コミに対する回答等の口コミID),kuchikomi_data(口コミ記事データ),regdate(登録日)、update_date(更新日)
※kuchikomi_idがプライマリキー

(4)t_matome[InnoDB]まとめ記事テーブル(商品カテゴリID別に必要数のテーブルを作成:1テーブル辺りの最大データ数約1000万件を想定) 
matome_id(autoincrement),user_id,pro_id,matome_data(まとめ記事データ),regdate(登録日)、update_date(更新日)
※matome_idがプライマリキー

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • 退会済みユーザー

    2016/10/20 12:38

    こちらの質問が他のユーザから「やってほしいことだけを記載した丸投げの質問」という指摘を受けました
    「質問を編集する」ボタンから編集を行い、調査したこと・試したことを記入していただくと、回答が得られやすくなります。

  • takepieee

    2016/10/20 12:56

    商用としてやるのであれば、プロジェクトチームを作ってやるレベルですよ。 個人運用するのであればトライするのも面白いと思いますが、多分ワイヤーフレームを作っていないような感じなので、作ってみてはいかがでしょうか。

    キャンセル

回答 3

+2

大規模化になる事を想定してテーブルを設計しようとする場合、どのように設計すれば、データ数が増えても処理がもたつかず、将来の拡張等にも対応しやすいのかが良くわかりません。 

データベース設計という面から言うと、
データベース設計の基本からしっかり押さえて、適正に正規化することで拡張性を保つことが出来ます。
正規化しすぎるとパフォーマンス面で不利になる場合もあるので、正規化した後にパフォーマンスを向上させるためにあえて非正規化する場合もあるかと思いますが、この辺りは拡張性とのトレードオフになります。

ので、強いて言えば、一度体系立ててデータベース設計について学習されるのが近道かと思います。

プロの方たちには不適切な質問、気に入らない丸投げ質問に見えてしまったようであれば申し訳ありません。 

丸投げというよりは、質問が具体的になっていない(何を質問していいのかわからないのだとは思います)、設計してみたテーブルを実際に試してみていない様に見えるのが

こちらの質問が他のユーザから「やってほしいことだけを記載した丸投げの質問」という指摘を受けました

というところにつながっているのかなと思います。

パフォーマンスについてはハードウェアの性能によっても変わるので、
想定されるハードウェアに近いかそれより弱い構成を作り(仮想マシンの設定やクラウド環境でのインスタンスタイプなどでいろんな環境を作れます)、実際に想定するデータを投入し、想定されるであろうSQLを投げてみて処理速度を計測するというステップを踏まれることをお勧めします。

その上で、これこれこう思ってこう試したけど、想定したパフォーマンスが出ない
という質問であればより具体的な回答が得られるかと思います。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+1

いきなり長く使えるものとか大規模とか考えないほうがいいですよ。
最初は自力でヘッポコでもいいから作って、運用してみて、そのうち出てきた問題点に対処していけば段階的に知見が貯まっていきます。そうした試行錯誤を経ずにここで「答え」だけ聞いて作っても、いずれ後で行き詰まります。

レコード数が100万件とか1000万件とか、MySQLならば十分に耐えられると思います。
しかしそんな心配を今からする必要はありません。
なぜなら、あなたが作ったサービスがそんな膨大なレコード数を格納するほどに発展する可能性は0.1%以下だからです。

完全に「取らぬ狸の皮算用」です。

もしヘッポコシステムのまま万が一ユーザー数が増えてきたら、そのとき初めてリファクタリングなりゼロから作り直しなりを検討しても遅くないですよ。
どうせ何事も当初の想定どおりにはいかないし、やっていくうちに気がつく問題点も多いので。

繰り返しになりますが、

  • あなたのWebサービスが大規模に成長する確率は低いので将来の心配は無用
  • 小規模でヘボくてもいいから自力で何個もサービス作ってるといろいろ分かってくる

以上二点が要旨です。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

kakaku.comは最初はあまりにも使いにくくてクレームがいっぱい出ました。クレームを管理してどんなバグのfixや機能改善でクレームを解消できるか管理する機能も必要でしょう。

ユーザーテーブルは最初仮登録して、メールで本人確認ができたら本登録する仕組みも必要ですし、ある程度の期間は履歴テーブルも用意してバグが発生した時に追跡できるようにしたいです。マナー違反の投稿を止めないユーザーは不良会員としてアカウントも停止とか、いろいろ出てくるでしょう。
掲示板だけでできる内容ではありません。

ERツールは使ってください。正規化はとりあえず第3正規化までやれば良いでしょう。

今さら kakaku.com の真似をしてもよほど使い勝手の良いシステムだとか、もっと安くて良いものが入手できるようなメリットがなければシェアは取れないでしょう。
データベース設計だけは最初からある程度きちんと作っておいた方が良いです。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.35%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

同じタグがついた質問を見る