0

ユーザーがまだシステムにいない人にタスクを割り当てることができるアプリがあります。

「some_user@example.com と共有」と入力すると、ユーザーは電子メールを受信し、そのユーザーとの友情が保留中であることに何らかの形で注意する必要があります。

私の友情表は次のように設定されています。

user_id:整数、friend_id:整数、status:文字列

シナリオ: 友人を追加する Steve の user_id = 2、fred の user_id = 6 友情が開始されると、友情テーブルに 2 つの行を追加します: (user_id, friend_id, status) (2, 6, requested) (6, 2, pending)

これは、両側からの友情をカバーしています。

私の質問は、まだサインアップしていないユーザーとの友情を処理するための良い習慣は何ですか.

私がこれまで行ってきた方法は、電子メールをステータスにして (私には適切ではないと感じました)、招待されたユーザーにトークンを含むリンクを送信することでした。ユーザーがそのリンクをクリックしたとき。サインアップ ページの URL にトークンを渡します。サインアップ時にコントローラーがそのトークンを見つけた場合、friendships テーブルで friends.status = "invited_user@email.com" を検索し、そのレコードを更新して、新しく作成されたユーザーの ID を指すようにします。

これは私には汚いと感じます（メールアドレスを保存して検索する）。

私が思いついた別の解決策は、友情の片側を作成することです (user_id = 3、friend_id = null、status ="invited")

query_string http://www.myapp.com/sign_up?invited_by=john@email.comで招待を送信します。

これで、メールで john の ID を見つけ、user_id = john.id AND status = "invite" の友情を見つけて、新しく作成した user_id で更新できます:受け入れた」）

次に、友情の残りの半分を作成します: (user_id = 36, friend_id = john.id, status = "accepted")

乱雑なトークンの送信や URL への埋め込みはありません (メールでクエリ文字列として招待するだけです)。

ユーザーが複数の招待状を持っている場合、招待されたユーザーの ID がまだわからないため、「招待」ステータスのレコードを使用できるため、それは実際には問題ではありません。

何か考えやより良い習慣はありますか?

4

1 に答える 1

1

あなたの最初の解決策が最善ではないことに同意します。データベースフィールドでクリエイティブにならないように、ずっと前に教訓を学びました。それらは 1 つの目的および 1 つの目的のみに使用する必要があります。(つまり、メールをステータス フィールドに格納しないでください。ステータスとステータスのみを格納します。)

2番目の解決策はうまくいくようです。

新しいエンティティの導入についてはどうですか？users と pending_users があります。2 つの異なるテーブルですが、それらの間にマッピングを行うことができます。

pending_user がサインアップすると、ある時点で「実際の」ユーザーになり、users テーブルに移行されます。

これは素晴らしい自然なセグメンテーションであり、クエリをもう少し直感的にすることができると思います。また、invite_by メールが URL から削除されます。

于 2013-06-07T23:10:20.240 に答える