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

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

新規登録して質問してみよう
ただいま回答率
85.50%
MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

Q&A

3回答

2369閲覧

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

ganbarunba

総合スコア8

MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

0グッド

0クリップ

投稿2016/10/20 03:35

編集2022/01/12 10:55

###前提・実現したいこと
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がプライマリキー

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

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

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

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

takepieee

2016/10/20 03:56

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

回答3

0

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

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

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

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

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

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

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

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

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

投稿2016/10/20 06:07

tanat

総合スコア18709

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

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

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

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

投稿2016/10/20 10:45

Orlofsky

総合スコア16415

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

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

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

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

繰り返しになりますが、

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

以上二点が要旨です。

投稿2016/10/20 06:00

zico_teratail

総合スコア907

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

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

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問