当朋友在 PHP/MySQL 应用程序中忽略某人时，我应该如何处理？
我有一个像 friends(friendship_id, fid1, fid2, ENUM('pending', 'accepted', 'ignored') 这样的表。当用户忽略某人的好友请求时，我想确保他们没有收到一条消息说“您已被忽略！”，但我也希望记录该数据，有关于如何处理此问题的建议吗？
I have a table like friends(friendship_id, fid1, fid2, ENUM('pending', 'accepted', 'ignored'). When a user ignores someone's friend request, I want to make sure that they don't get a message saying, "You've been ignored!", but I also want that data logged. Any suggestions on how to approach this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
显然，您应该做的第一件事就是不要实现任何会显示
您已被忽略！消息的代码。这可以解决您的大部分问题。但你必须要小心一点。还有一个更微妙的问题 - 从发件人的角度来看，您的系统在各个方面都应该表现得好像用户没有单击“忽略”。这意味着，如果发件人发出第二个请求，并且通常您的系统会显示“您已经向该用户发送了请求”，那么即使收件人忽略了第一个请求，它也应该继续显示此消息。您需要小心，不要通过更改消息来响应本应保密的事件而泄露信息。
对评论的回应：
我认为这有点超出了这个问题的范围，而且本身就是一个漫长的讨论，所以我只会在这里触及它。答案取决于您的应用程序的实施方式。简短的答案是：您的应用程序应该帮助您的用户并且直观，因此如果消息对他们有帮助，那么就添加它。
另一种方法是，如果一周后没有回复，请求将自动过期。当前请求过期后，您可以允许用户提出新请求。您可能需要考虑忽略请求是否意味着仅忽略该用户的一个请求或所有请求。
友谊请求是定向关系。您有一个发送者和一个接收者。另一方面，友谊通常（但并非总是）被认为是无方向的关系。好友请求通常会有一条相关消息“嘿，还记得我吗？我们昨晚在酒吧见过面！”。另一方面，建立的友谊通常没有与之相关的消息。因此，将这些不同类型的关系存储在数据库的不同表中可能是有意义的。
Obviously the first thing you should do is to not implement any code that would display the
You've been ignored!message. This solves most of your issue.But you have to be a little careful. There is a more subtle issue - your system should behave from the sender's viewpoint in every way as if the user hadn't clicked ignore. That means that if the sender issues a second request and normally your system says "You have already sent a request to this user" then it should continue to display this message even after the recipient has ignored the first request. You need to be careful not to leak out information by changing messages in response to an event that was supposed to be private.
Response to comments:
I think this is a bit out of scope for this question and is a long discussion in itself so I will only touch upon it here. The answer depends on how your application is implemented. The short answer is: your application should help your users and be intuitive so if the message helps them then add it.
An alternative is that requests expire automatically after one week if there is no reply. Once the current request has expired you can allow the user to make a new request. You might want to consider if ignoring a request means ignoring just that one request or all requests from that user.
Friendship requests are directed relationships. You have a sender and a receiver. Friendships on the other hand are usually (but not always) considered to be undirected relationships. A friendship request will usually have a message associated with it "Hey, remember me? We met in the bar last night!". On the other hand an established friendship does not typically have a message associated with it. So it might make sense to store these different types of relationship in different tables in your database.
如何区分谁忽略了谁？如果一个朋友忽略了另一个，那么我想
ENUM将更改为“忽略”，并且被忽略的朋友也会成为忽略的朋友。您可以分辨出谁忽略了您，因为您似乎也忽略了他们。最好放置一个中间表，例如
ignore(ignorer,ignoree)，其中的列只是好友 ID。这样，每当向一个朋友发送消息、更新等任何信息时，应用程序都会首先检查目标朋友是否忽略源朋友。How are you distinguishing who ignored who? If one friend ignores the other, then I suppose that
ENUMwould be changed to 'ignored', and the ignored friend would also become the ignoring friend. You could tell who has ignored you, because you would appear to be ignoring them as well.Better to put an intermediate table, like
ignore(ignorer, ignoree), where the columns are just friend IDs. That way whenever a message, update... whatever, is sent to one friend, the app first checks whether the destination friend is ignoring the source friend.我最近在我正在编写的应用程序中实现了这一点。我实际上在数据库中有两行。我的列是 sourceUserId 和 destUserId。当某人（A）向另一个人（B）发送请求时，它会自动插入一行，其中 A 的 UserId 作为 sourceUserId，B 的 UserId 作为 destUserId。如果他们再次发送，它会注意到该行已经存在。要让 B 批准 A，请插入 B 的 UserId 作为 sourceUserId，插入 A 的 UserId 作为 destUserId。
我的应用程序还有一个通知表，因此每次有人添加其他人（即成功插入 A 的 UserId=sourceUserId 和 B 的 UserId=destUserId 的行）时，都会向目的地发送一条通知。
要检查两个人是否是朋友，您只需检查互惠行是否存在即可。
I implemented this recently in application I'm writing. I actually had two rows in the database. My columns were sourceUserId and destUserId. When someone (person A) sends a request to another person (person B), it automatically inserts a row with A's UserId as the sourceUserId and B's UserId as the destUserId. If they send it again, it notices that the row already exists. To have B approve A, insert B's UserId as the sourceUserId and A's UserId as the destUserId.
My application also had a notification table, so each time someone adds someone else (i.e. the row with A's UserId=sourceUserId and B's UserId=destUserId is successfully inserted), a notification is sent to the destination.
To check if two people are friends, you simply check if the reciprocal rows exist.
示例：
用户A向用户B发送好友请求，用户B忽略了该请求：
用户 A 不知道他/她的请求已被忽略。对于用户 A，此请求状态应视为“待处理”。
对于相同的 2 个用户：
即使用户 B 忽略了用户 A 的请求，也并不一定意味着用户 B 不能尝试与用户 A 成为朋友。此类操作应该清除之前对用户 A 的请求的“忽略”（就好像它从未发生过一样）。
所以你的表架构没问题。你只需要考虑所有可能场景的语言和逻辑。
Example:
User A sent friend request to user B, user B ignored this request:
User A does not know that his/her request has been ignored. To user A this request status should be seen as 'pending'.
For same 2 users:
Even though user B ignored user A's request, it does not necessarily entail that user B can't try to become friends with user A. Such action should clear previous 'ignore' of user A's request (as if it never happened).
So your table schema is okay. You just have to think about the language and logic of all possible scenarios.