PHPとMySQLについて

サイトの作成を考えています。会員登録してその会員のデータをPHPで編集したり、表示したりするサイト
例えば、
|会員NO|会員ID|パスワード|メールアドレス| のような会員情報があり、
入会時には会員ごとの
お気に入りWEBページ|ページの評価1~5|コメント| ×N個
お気に入りの書籍|本の評価1~5|コメント|  ×N個
のようなテーブル?(始めは空でユーザが登録していける) を自動で作る感じです。

これって、MySQLでできるのでしょうか?
どんなDB設計にすればよいか教えてください。
可能であればPHPでのDB操作イメージ、ソースがあると助かります。

回答の条件
  • 1人5回まで
  • 13歳以上
  • 登録:2012/05/25 21:50:05
  • 終了:2012/05/28 23:05:38

ベストアンサー

id:pretaroe No.1

pretaroe回答回数531ベストアンサー獲得回数752012/05/26 00:29:16

ポイント110pt

>これって、MySQLでできるのでしょうか?

できます。

>どんなDB設計にすればよいか教えてください。

やり方はいろいろありますが、まずは質問文通りに作成してみては?

・会員情報テーブル
|会員NO|会員ID|パスワード|メールアドレス| 、

・お気に入りのWEBページテーブル
|会員NO|お気に入りWEBページ|ページの評価1~5|コメント| 

・お気に入りの書籍テーブル
|会員NO|お気に入りの書籍|本の評価1~5|コメント| 

会員NOで1対多になるように作るだけ


>可能であればPHPでのDB操作イメージ、ソースがあると助かります

PHPプロ!PHP講座
http://www.phppro.jp/school/mysql/

------------
追記:
グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)
梅田 弘之
479810566X

顧客管理とか見つからなかったので販売管理で。

1枚の伝票に複数の明細がつきます。

1枚の伝票=会員
明細=お気に入りのXXX

にあたります。

1枚の伝票:明細=1:N 対応と言います。

>『お気に入りのWEBページテーブル』というのは全体でひとつというイメージでしょうか?
>ユーザ毎にあったほうが、検索スピードとかが速くなるとか、
>例えば会員が1万人いてそれぞれが、100件お気に入り~を登録したら、
>100万件のレコードが格納されるわけですが、そんなもんなんでしょうか?

全体で1つですよ。

100万件のレコードでも最近は問題ないぐらいの速度が出ますよ。

テーブル設計はこれで一般的です。
普通にテーブルの正規化を行うだけです。

速度に問題が生じるとか生じた段階で方式を考えるわけですね。 

他1件のコメントを見る
id:pretaroe

回答に追記して補足しました。



>例えば会員が1万人いてそれぞれが、100件お気に入り~を登録したら、
>100万件のレコードが格納されるわけですが、そんなもんなんでしょうか?

データベースはそういう大量の件数を扱えるようになっています。
検索のやり方にもよりますが、インデックスキーを使う限りは、管理速いです。

2012/05/26 03:46:11
id:gwrite

ありがとうございます! 大変わかりやすく理解できました。
ついでで申し訳ないのですが、DBに登録する常識的な? データ(レコード? フィールド?)サイズの上限など
ご存知でしたら教えてください。
コメントなどは何百文字でも全然問題ないのでしょうか?
データが何バイトを超えだしたところから、DBに登録するのを避けるべきとか
ありますか?
今後長文データなどの扱いをどうするのかで、悩むと思います。

2012/05/26 10:26:27

その他の回答(1件)

id:pretaroe No.1

pretaroe回答回数531ベストアンサー獲得回数752012/05/26 00:29:16ここでベストアンサー

ポイント110pt

>これって、MySQLでできるのでしょうか?

できます。

>どんなDB設計にすればよいか教えてください。

やり方はいろいろありますが、まずは質問文通りに作成してみては?

・会員情報テーブル
|会員NO|会員ID|パスワード|メールアドレス| 、

・お気に入りのWEBページテーブル
|会員NO|お気に入りWEBページ|ページの評価1~5|コメント| 

・お気に入りの書籍テーブル
|会員NO|お気に入りの書籍|本の評価1~5|コメント| 

会員NOで1対多になるように作るだけ


>可能であればPHPでのDB操作イメージ、ソースがあると助かります

PHPプロ!PHP講座
http://www.phppro.jp/school/mysql/

------------
追記:
グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)
梅田 弘之
479810566X

顧客管理とか見つからなかったので販売管理で。

1枚の伝票に複数の明細がつきます。

1枚の伝票=会員
明細=お気に入りのXXX

にあたります。

1枚の伝票:明細=1:N 対応と言います。

>『お気に入りのWEBページテーブル』というのは全体でひとつというイメージでしょうか?
>ユーザ毎にあったほうが、検索スピードとかが速くなるとか、
>例えば会員が1万人いてそれぞれが、100件お気に入り~を登録したら、
>100万件のレコードが格納されるわけですが、そんなもんなんでしょうか?

全体で1つですよ。

100万件のレコードでも最近は問題ないぐらいの速度が出ますよ。

テーブル設計はこれで一般的です。
普通にテーブルの正規化を行うだけです。

速度に問題が生じるとか生じた段階で方式を考えるわけですね。 

他1件のコメントを見る
id:pretaroe

回答に追記して補足しました。



>例えば会員が1万人いてそれぞれが、100件お気に入り~を登録したら、
>100万件のレコードが格納されるわけですが、そんなもんなんでしょうか?

データベースはそういう大量の件数を扱えるようになっています。
検索のやり方にもよりますが、インデックスキーを使う限りは、管理速いです。

2012/05/26 03:46:11
id:gwrite

ありがとうございます! 大変わかりやすく理解できました。
ついでで申し訳ないのですが、DBに登録する常識的な? データ(レコード? フィールド?)サイズの上限など
ご存知でしたら教えてください。
コメントなどは何百文字でも全然問題ないのでしょうか?
データが何バイトを超えだしたところから、DBに登録するのを避けるべきとか
ありますか?
今後長文データなどの扱いをどうするのかで、悩むと思います。

2012/05/26 10:26:27
id:oil999 No.2

oil999回答回数1728ベストアンサー獲得回数3202012/05/27 10:03:01

>これって、MySQLでできるのでしょうか?
できます。

次のようなテーブルを作るといいでしょう。
会員IDが一意であると想定しています。

member(会員情報)

カラム名内容
no会員NO
id会員ID
pswパスワード
emailメールアドレス

favorite_sites(お気に入りWEBページ)

カラム名内容
id会員ID
urlWEBページのURL
evalページの評価
commentコメント

favorite_books(お気に入りの書籍)

カラム名内容
id会員ID
isbn書籍のISBN番号
title書籍のタイトル
eval書籍の評価
commentコメント

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません