我有一个应用程序，允许用户将任务分配给尚未进入系统的人。
一旦我输入“与some_user@example.com分享”，用户将收到一封电子邮件，我将不得不注意到我与该用户有待处理的友情。
我的友谊表设置如下：
user_id：integer，friend_id：integer，status：string
场景：添加好友 Steve的user_id = 2，fred的user_id = 6 当友谊开始时，我向友谊表添加两行： （user_id，friend_id，status） （2,6，要求） （6,2待定）
这涵盖了双方的友谊。
我的问题是，处理与用户尚未注册的友谊的良好做法是什么。
到目前为止，我做的方式是将电子邮件置于状态（对我来说感觉不对），并向受邀用户发送带有令牌的链接。当用户单击该链接时。他们将URL中的令牌传递给注册页面。如果在注册时，我的控制器看到该令牌，我将在friendships表中搜索friendships.status =“invite_user@email.com”并更新该记录以指向新创建的用户的id。
这对我来说很脏（存储电子邮件地址并进行搜索）。
我刚才提出的另一个解决方案是创造友谊的一面 （user_id = 3，friend_id = null，status =“invite”）
并使用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 = john.id，friend_id = invite.id，status =“accepted”）
然后创造友谊的另一半： （user_id = 36，friend_id = john.id，status =“accepted”）
在网址中没有杂乱的令牌发送或嵌入（仅作为查询字符串通过电子邮件邀请）。
如果用户有多个邀请，这并不重要，因为任何状态为“邀请”的记录都可以使用，因为我们还不知道被邀请用户的ID。
任何想法或更好的做法？
答案 0 :(得分：1)
我同意你的第一个解决方案不是最好的。很久很久以前就学到了这个教训，以免在数据库领域发挥创意。它们应该仅用于一个目的和一个目的。 （换句话说，不要在状态字段中存储电子邮件。存储状态和仅状态。）
第二种解决方案似乎有效。
引入新实体怎么样？你有用户和pending_users。两个不同的表，但您仍然可以在它们之间进行映射。
如果pending_user注册，他们可以成为“真正的”用户并迁移到users表。
这是一个很好的自然分段，我想可以让查询更直观一些 - 它会从URL中删除invite_by电子邮件。