友達招待機能

Question

先ほど、友達管理機能についてご質問させていただきましたが、その続きでご質問させていただきます。

会員さんが、非会員の人を招待する機能を考えております。

想定しているフローは以下の通りです。
(0)招待用テーブルの用意
(1)会員が招待したい人のメールアドレスを入力して招待ボタンをクリック
(2)ユニークなIDを発行して、登録URLにIDをくっつけて発行する。（http://hoge.com/create?id=ユニークな値）
(3)発行したユニークなIDをDBに保存
(4)招待されたユーザーがそのURLをクリックし、アカウント登録をする
(5)パラメータのIDをサーバー側に送信？
...

ざっくりここまで想定していますが、(5)からの流れをどうしようか悩んでおります。
また、それ以前に上記のフローがよいのかもご相談したく思います。

そもそも
(0)招待用テーブルの用意
は必要なのでしょうか？

招待用テーブル
ID
招待した会員ID
発行したユニークID
招待ステータス？

発行URLのところまではなんとなくイメージがつきますが、
招待されたユーザーが登録した際に、招待したユーザーと招待されたユーザーは、「友達」という扱いをしたいのでどう紐づけるか、がポイントだと思ってます。

アドバイス頂ければと存じます。

Answer 1

想像出来る解決方法

(0)に関して
招待用テーブルは必要です。yambejpさん同様、一時保存用になります。
URLの有効制限時間をもうけておいて、有効時間がきれたものはbatchで削除するとよいです。
仮にURLの有効時間が24時間だとしたら、
削除batchでは、余裕を持って25時間たったものを削除するとよいです。（登録するタイミングと削除するタイミングがかぶったときに、招待用レコードがきえていたらこまるため）

(5)サーバに送信？というのは、このテーブル設計はAPIでつかうものなのでしょうか。
どちらにせよ、サーバ内で、招待者のユーザ登録をする処理が終わったら、
友達管理テーブルに、レコードを追加すればよいかと思います。
招待用テーブルのユニークIDで、招待元の会員はわかるかと思います。
招待されたユーザが登録完了をしたら、招待用テーブルのユニークID（URLにくっつけたやつ）から招待元ユーザのIDをとってきて、友達管理テーブルに入れておきます。

Answer 2

(0)招待用テーブルの用意は必要なのでしょうか？

どちらとも言えない。

非会員が正会員になる可能性が高いなら会員管理用テーブルを最初から利用しても
よいかと思いますが、非会員へのリクエストが頻発する割に、会員にシフトしないなら
無駄がおおいので、一時保存用の非会員用テーブルのほうがよいかも。
ただどちらの場合でも定期処理で何日間以上保留になっているリクエストは削除するという
メンテナンスをすればよいので非会員テーブルを使うメリットはauto_incrementによる
ID発行に無駄な抜け番がでにくいくらい？

とくに勧誘が多発したときにスパムとして認識される可能性もあるので
ヒット率の低い勧誘者はペナルティが必要になるかも