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

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

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

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

PHP

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

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

Q&A

解決済

1回答

12933閲覧

facebookライクなSNSのDBテーブル構造について

sika

総合スコア52

SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

PHP

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

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

0グッド

8クリップ

投稿2017/12/10 10:41

現在、facebookライクのSNSをPHPで開発をするためのDB設計を行っています

仕様としてはfacebookの主要仕様をベースに考えています

  • 友達リクエスト → リクエスト認証されたら友達として紐付け
  • 自身の投稿の際に"自分のみ"、"友達のみ"、"全体"の公開範囲の設定が可能
  • 投稿にいいねボタンを押したカウント数とメンバーの一覧表示が可能
  • メッセンジャー機能やグループ機能などは現時点では不要

現在の懸念点

  • 投稿または返信コメントのリアルタイムな反映を考慮した場合にfirebaseの様なリアルタイム同期型データベースのサービスの導入は好手か悪手か?また導入した際に現在のテーブル構造はどうあるべきか?
  • 投稿に対して返信コメントがあり、さらにその返信に対してのコメントがあった場合の階層型としてのテーブルの持ち方をした場合に、出力の際のSQL構文が浮かばない(あまりに複雑になってしまう場合は直列型へ仕様を変更)
  • 友達テーブルでお互いの友達関係を紐付けるレコード数が「誰が」「誰を」という現在の構造では、お互いが友達という関係を証明するのにレコードが2行分必要な構造は無駄ではないのか?(後々に片方が友達削除した場合などを考えた際に更新処理が複雑になるのではないか?)

当方、複数のテーブルを用いた設計が初めてですので、上記の懸念点と下記テーブル構想に対してのご指摘・ご教授など頂ければ幸いです。

現在構想中のテーブル一覧です↓

【ユーザー情報table】『user_table』
|u_id|u_account|u_pass|u_mail|u_lname|u_fname|u_thumb|u_gender|u_by|u_bm|u_bd|u_hide|u_remove|u_signin|
|:--|:--:|--:|
|ユーザーID|アカウント表記名|パスワード|メールアドレス|姓|名|サムネイル画像|性別|誕生日(年)|誕生日(月)|誕生日(日)|退会状態フラグ|削除状態フラグ|登録日


【友達関係table】『freind_table』
|f_id|f_follow|f_followers|f_request|f_approval|
|:--|:--:|--:|
|フレンドID|フォロー側ユーザーID|フォロワー側ユーザーID|友達申請フラグ|認証フラグ|


【投稿関連table】『post_table』
|p_id|p_user|p_date|p_text|p_img|p_release|p_like|p_comment|p_hide|
|:--|:--:|--:|
|コメントID|投稿ユーザーID|投稿日時|投稿内容|添付画像|公開範囲フラグ|いいねカウント|コメント数カウント|非表示フラグ|


【返信コメントtable】『reply_table』
|r_id|r_post|r_date|r_user|r_text|r_img|r_like|r_comment|r_emoji|
|:--|:--:|--:|
|返信ID|返信元コメントID|返信日時|返信ユーザーID|返信内容|添付画像|いいねカウント|コメント数カウント|絵文字ナンバー|


【いいねtable】『like_table』
|l_id|l_post|l_reply|l_user|l_partner|l_count|l_date|
|:--|:--:|--:|
|いいねID|投稿ID|返信ID|クリックユーザーID|相手ユーザーID|カウント数|クリック日時|

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

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

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

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

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

guest

回答1

0

ベストアンサー

自分の最適化だとこうかな 関係ない情報は割愛してますが

ユーザーを表す (users etc)

column---typekeycomment
idintPRIMARY KEYユーザ

※ RIMARY KEY(id)


フォロー関係を表す (friends etc)

columntypekeycomment
idintFOREIGN KEY : users(id)ユーザ
friend_idintFOREIGN KEY : users(id)フォロ

※ RIMARY KEY(id,friend_id)


コメント投稿を表す (posts etc)

column---typekeycomment
idintPRIMARY KEYポスト
user_idintFOREIGN KEY : users(id)ユーザ
parent_idintFOREIGN KEY : users(id)親記事

※ parent_id = null が親記事
※ RIMARY KEY(id)


いいねを表す (favorites etc)

columntypekeycomment
idintFOREIGN KEY : users(id)ユーザ
post_idintFOREIGN KEY : posts(id)フォロ

※ RIMARY KEY(id,post_id)

投稿2017/12/10 13:50

編集2017/12/10 13:51
退会済みユーザー

退会済みユーザー

総合スコア0

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

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

sika

2017/12/12 07:31

ご回答ありがとうございます。 FOREIGN KEYという物の存在は知っていましたが、こういう場合に用いるのですね! ご提案していただいた最適化テーブルをもとに再度設計を練り直してみたいと思います。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

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

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

質問する

関連した質問