よくあるフォロー機能のテーブル構成を考えてみる

スポンサーリンク
Pocket
LINEで送る

最近DB設計の楽しさに気付いていろんなWebサービスのDB構成を考えています。

今回は、SNSに必ず存在するフォロー機能または、友達機能についてを考えてみます。

 

フォロー機能を使うパターン

フォロー機能とは、自分が気になった相手をフォローする機能です。

フォローすると相手の投稿が自分のタイムラインに表示されるので相手のページに進まなくてもよくなります。

ツイッターやFacebook、インスタグラムなどSNSにはほぼこの機能が備わっています。

フォロー機能を使うパターンを考えてみます。

・自分をフォローしているユーザー一覧

・自分がフォローしているユーザー一覧

 

テーブル構成

テーブル一個でできました。

follow
– id
-user_id (自分のユーザーID)
-follows_user_id (フォローしているユーザーID)
-created_at (フォローした日)

このテーブルがあれば上記の機能をすべて実現できます。

user_idに自分のID、follows_user_idにフォローする相手のIDを格納します。

 

※カラム名を以下にした方がいいかもしれません

フォローするユーザーIDをfollow_id

フォローしているユーザーIDをfollower_id

 

自分をフォローしているユーザーを取得

SELECT FROM follow
  JOIN INNER users
  ON follow.user_id = user.id
  WHERE follows_user_id = “自分のID”

 

自分がフォローしているユーザー

SELECT FROM follow
  JOIN INNER users
  ON follow.follows_user_id = user.id
  WHERE user_id = “自分のID”

 

ツイッターはフォローと被フォローのテーブルを分けている

スポンサーリンク

フォローと被フォローの関係をそれぞれ別にデータに持つこと。論理的には片方向のグラフだけ持っておけば十分だが、あえて「誰をフォローしているか」「誰にフォローされているか」に分けてデータ化しておく。データの整合性に気を付ける必要はあるものの、こうしておけばクエリは特定パーティションへのアクセスで完結するため、メモリに乗り切らないという問題も解消するのだという。

http://www.atmarkit.co.jp/news/201004/19/twitter.html

 

ツイッター並の規模になるならこういった構成に変えないといけませんね。