はじめに
ツイッターやフェイスブックなどで何気なく押しているフォローボタン。たかがフォローボタンと言えど、考えてみると奥深い。今回は、これについて考えてみる。
テーブル設計
フォローボタンのテーブル設計として、例えば下記の2つが考えられる。
table_user_follow その１
| カラム | 説明 |
|---|---|
| user_id | ユーザid |
| user_id_follow | フォローしているユーザid |
| datetime_follow | フォロー日時 |
説明
最初は空テーブルで、フォローするごとにフォローしたユーザを追加していく。
table_user_follow その２
| カラム | 説明 |
|---|---|
| user_id | ユーザid |
| user_id_follow | フォローしているユーザid |
| datetime_follow | フォロー日時 |
| flag_follow | フォローしてるか(true/false) |
説明
最初に全ユーザをflag_follow = falseとして登録しておき、フォローした場合、flag_follow = trueとする。
結論
上記を比較した場合、結論として後者はレコード数がユーザ数×ユーザ数分必要になり、レコード数が膨大になるので、前者の方が適当だろう。と言う訳で、テーブルは前者を使用する。
ロジック
テーブル設計が決まったので、次にフォローボタンを押した時の処理について考える。
フォローボタンを押した時の処理として、テーブルにフォローユーザを登録すればそれで良いのかと言うと、そう言う訳にもいかない様だ。
では、その他にどう言った処理が必要なのだろうか？
ブラウザの2重起動問題
WEBアプリを作成する場合は、ブラウザの2重起動問題と言うものを考える必要がある（別に2重でなくても、5重でも10重でも良いのだが）。
つまり、同じ画面を複数のタブもしくはブラウザ（chrome + edgeなど）で起動しておいて、同じユーザをフォローした場合、上記の様なフォローユーザを登録のみの処理だと、同じユーザのレコードがテーブルに複数登録されてしまう。
なので、例えばタブを数百個開いておいて、同じユーザをフォローするといきなりフォロワーが数百人になるというチートが使えてしまうことになってしまう。
これは、テーブル設計としては見直す必要がある。
ロジック（修正版）
では、フォロー処理についてどの様な処理が必要か考えてみる。
結論としては、下記の様な処理が必要かもしれない。
（私はSNS会社に勤めたことは無いので、あくまで推論である。）
１．自分のアカウントが存在するか
２．フォローするアカウントが存在するか
３．既にフォローしていないか
４．（フォローしていない場合）フォロー処理
５．総フォロー数の更新
６．総フォロワー数の更新
１～２については、他のブラウザで既にアカウントを削除していた場合、フォローすると矛盾が生じるので、アカウントの存在を確認する必要がある。
３については、上述の様に既にフォローしている場合は、レコードを登録する必要はない。
１～３をクリアした場合のみ、４でフォロー処理を行う。
５～６については、別のテーブルでフォロー数、フォロワー数を管理している場合、そのレコードを更新する。
ざっと考えただけで、これだけの処理が必要になる。
単純に登録すれば良いという訳でもないことが、お分かり頂けたと思う。
結論
普段、何気なく使っているフォローボタン。その裏にもそれなりに考えられたロジックが存在する。案外、世の中なんてそんなもので、自分の周りにも、（気づかないだけで）他の人が試行錯誤を重ねた商品が多く存在するのかもしれない。そう言った商品やロジックに思いを巡らせてみるのも面白そうだし、新たな発見に繋がりそうでもある。