フレンドリストを作成する際の設計について
- 初心者が考えるSNSのフレンドリストの設計について説明します。
- フレンドリストの最大数が1000の場合、どのような設計が適切かについて検討します。
- テーブルの作成方法やカラムの管理方法についても考えます。
- ベストアンサー
フレンドリストのようなものを作る場合の設計
かなり初心者です。もしかしたら妙な事を訊いているのかもしれません。 php5.4.16とmysql5.5.32でSNSのフレンドリストのような機能を作ろうと思います。 フレンド最大数は1000とします。この場合、1000個もカラムを作るのでしょうか? それとも、会員個別にテーブルを作ってそこで管理するのでしょうか。 もしくは、テーブルは一つとし、会員番号のカラムを二つ用意、関係性を示したテーブルを作るのでしょうか? もしくは、カラムは一個で文字列で操作したりするのでしょうか?(カンマで区切る等) パフォーマンス的にどの設計が正しくて、どの設計が間違いなのでしょうか… 回答よろしくお願いします。
- auau5656
- お礼率100% (36/36)
- MySQL
- 回答数2
- ありがとう数2
- みんなの回答 (2)
- 専門家の回答
質問者が選んだベストアンサー
こんなデータの持ち方をすると集計しやすいかと 仮に長野、亀井、坂本、阿部、村田の5人がいて、 長野は亀井と友達、阿部は長野、亀井、坂本と友達、村田はぼっちだとすると //元データ create table user(uid int not null unique ,name varchar(20)); insert into user values(1,'長野'),(2,'亀井'),(3,'坂本'),(4,'阿部'),(5,'村田'); create table friend(id int primary key auto_increment,fid int,uid int,unique(fid,uid)); insert into friend(fid,uid) values(1,1),(1,2),(2,1),(2,4),(3,2),(3,4),(4,3),(4,4); ※friendテーブルのfidは友達二人をつなぐためのリンク用id (1)各自友達が何人いるか集計する select user.uid,name,coalesce(count,0) as count from user left join( select uid,count(*) as count from friend group by uid ) as sub on sub.uid=user.uid order by uid; (2)各自の友達の名前を羅列する select u1.uid,u1.name,friends from user as u1 left join( select f1.uid,group_concat(u2.name) as friends from friend as f1 inner join friend as f2 on f1.fid=f2.fid and not f1.uid=f2.uid inner join user as u2 on f2.uid=u2.uid group by uid ) as sub on u1.uid=sub.uid
その他の回答 (1)
- t_ohta
- ベストアンサー率38% (5083/13283)
通常なら「テーブルは一つとし、会員番号のカラムを二つ用意、関係性を示したテーブルを作る」だと思います。
お礼
回答有り難うございます。
関連するQ&A
- 効率のよいテーブル設計について
個人運営ですが、Win2000+Appache+MYSQLを使って会員性のブログのようなサイトをやっています。 DBの設計をなおそうと思っているのですが、以下、どちらの設計のほうが効率が良いのでしょうか。 1)会員毎にテーブルを用意しそこにブログを記録。 2)1つのテーブルで会員全てのブログを記録。(会員番号にインデックス。) ご教授よろしくお願いいたします。
- ベストアンサー
- MySQL
- リストボックスのリストの数について
こんにちは phpでmysqlのテーブルデータをリストボックスで表示させ 選択できるようにしました。 ここで質問なのですが、表示できるリストは最大いくつなのでしょうか?? 140あるデータで試したのですが、99くらいしか表示できませんでした。 これは決まりなのでしょうか? ほかに全て表示させる方法がありますでしょうか? よろしくお願いします。
- ベストアンサー
- PHP
- テーブル設計について
先日明解なアドバイスを頂いたばかりなのですが、もう一つだけ別件で疑問点が出たので質問致します。 簡素なウェブアプリケーションを作成しようとしています。テーブルの設計をしているところなのですが、どのようなテーブル設計にすればよいのか見当がつかないのでアドバイスを頂きたいです。 仮にスタッフというテーブルがあるとします。今のところスタッフテーブルには名前、性別、生年月日というカラムしかありません。このシステム、「シフトスケジュール」という考え方を盛り込みたいです。例えば、2009年6月1日はAさん、Bさんがスタッフとして勤務し、2日はBさんとCさんが勤務する。。といったようなアルバイトのイメージです。 この場合、「シフト」といった新しいテーブルを作った方がいいような気がするのですが、一体どのようなカラムをどのような型で用意すればいいのかわかりません。どんなシステムにしたいかに依存するとは思いますが、これから作ろうとしているシステムは業務用でなく自己学習用なので最低限必要な簡素なレベルにしたいのです。ざっくりな感じで構わないのでカラム、テーブルのアドバイスを頂けると助かります。ちなみにMySQLを使用する予定です。
- ベストアンサー
- その他(データベース)
- テーブル設計について
会員制の小さなサイトを運営しています。 会員は会員IDで管理しているのですが、テーブル設計が適切であるか判断できず、助言を頂きたく書き込みさせて頂きました。 現在、会員情報テーブル(info)というテーブルが全ての基本となっています。 このテーブルには、会員IDの他、名前や性別、住所、自己紹介文などほとんど全ての会員情報が含まれています。 このほかに会員同士の交流用のテーブル(koryu)がいくつかあり、 そこには、会員IDとその会員が行った内容が記録されています。 で、現状、交流用テーブルを使用する場合、常に会員の名前を会員情報テーブルから引っ張ってきており、これが、処理的に重いのでは無いか、と思っています。 以下はたとえばの例ですが、 select koryu.id, info.name, koryu.contents from info,koryu where koryu.id=info.id のように、毎回、(ほぼ)名前だけを引っ張ってきています。 引っかかっているのは、この「名前だけ」というところで、例えば、会員IDと名前しかないテーブルを作成すれば、もしかしたら、処理が軽くなるのでは・・と思っているのです。 20カラムあるテーブルと関連付けを行う場合と、2カラムのテーブルと関連付けを行う場合、 2カラムのテーブルのほうが、処理は軽くなるのでしょうか?また、軽くなる場合、そうしたほうが良いのでしょうか? (現在、1000名くらいしか会員がいないため、処理が重いということは無いのですが、 安いサーバを使用しているため、処理はなるべく軽くしておきたいと思っています。) よろしくお願いします。
- ベストアンサー
- MySQL
- 会員システム 複数のユーザー同時操作 設計
MySQL4+PHP4でデータベースを構築している初心者です。 今回1000人規模の会員システムを構築する予定で設計を考えていますが、経験者の皆様にアドバイス頂けましたら幸いです! ■■ 概 要 ■■■ ・各ユーザーはメールアドレスと任意のパスワードで好きなときにログインできる ・各会員は自分を紹介するページが1ページ割り当てられていていつでもコメントやプロフィールを変更できる ・各会員はサイトから住所や年齢で検索をかけて会員情報を絞り込める ■■ 検討点 ■■(皆様にアドバイス頂きたい部分です。) (1)各会員の情報は主に10個くらい(名前、年齢、住所、コメント・・・等)ですが、テーブルを1つ作って1カラムを1会員に割り当てる設計で基本的に問題ないでしょうか・・・? (複数の会員が同時刻に操作する場合がありますが、1つのテーブルをみんなで開き、更新しあって安定して動きますでしょうか・・・?) (2)大雑把な質問ですが、他に設計上何か気をつけた方が良いことなどありましたら、アドバイス頂けましたら幸いです! 上級者の方々のアドバイスが本当に貴重でいつも教gooを重宝しております。皆様お忙しいところすみませんが、どうぞ良きアドバイスをよろしくお願いします!!
- ベストアンサー
- MySQL
- カテゴリのDB設計について
お世話になります。 商品データとカテゴリテーブルをそれぞれ分けたデータベースを作っており、JOINで該当カテゴリ名を抽出しています。 しかし商品によって複数のカテゴリに属する(カンマ区切りで「1,2,3」というように現状格納しています)場合、それらのすべてを拾ってくることは可能でしょうか? またカテゴリひとつひとつに対して商品データ内にカラムを用意するべきでしょうか? select `shop`.no, left outer join list_category on `shop`.category=`list_category`.no (現状) どうぞよろしくお願い致します。
- ベストアンサー
- MySQL
- 掲示板のDBテーブル設計について
今phpとmysqlを使って掲示板を作ってみようと考えています。 そこでDBのテーブル設計なのですが、スレッド1つに対してレスポンス用のテーブルを1つ作るか、スレッドとレスポンスのテーブルを1つずつ作成して運用するかどちらがいいか迷ってます。 後者のレスポンステーブルを1つにまとめるのはやはりアクセスが集中しそうなのでよくないでしょうか? よろしくお願いします。
- 締切済み
- SQL Server
- MySQLからフィールド名のリストを取り出し、一部のフィールド名を除外したい場合
PHP + MySQLにて テーブルからフィールド名だけを取得し、さらに一部のフィールド名を除外したいです。 レコードじゃないのでis not構文は使えませんでした。 何かいい方法があれば教えてください。 $sql = "select * from table"; //tableテーブルからフィールド名を取り出し $rs = mysql_query($sql); $fields = mysql_num_fields($rs); $column = array(); for ( $i=0; $i<$fields; $i++ ) { $column[$i] = mysql_field_name($rs, $i); }
- ベストアンサー
- MySQL
- 2パターンのデータベース設計で最適なほうはどちら?
こんにちは。 データベース設計をするにあたり、迷っています。 言語はRuby on rails、DBはMysqlです。 たとえば日記サイトを作るとして (1)テーブル : users , diariesがあって、それぞれのidはuser_diaries というリレーション用のテーブルを作って持たせる (2)テーブル : users , diariesがあって、diaries にuser_id というカラムを持たせる というような作り方ができると思うのですが、どちらが優れていると言えるでしょうか? 決めの問題でしょうか? 将来的に大きなサイトになっても大丈夫なようにしておきたいです
- 締切済み
- MySQL
お礼
回答有り難うございます。