Question

我的应用中有一个要求，即一个用户可以将好友请求发送给另一个用户。我们使用SQL Server数据库作为后端。表的结构是这样的。

CREATE TABLE FriendStatus
(FriendStatusId BIGINT PRIMARY KEY IDENTITY(1,1),
FromUserId BIGINT,
ToUserId BIGINT,
StatusId TINYINT,
SentTime DATETIME2,
ResponseTime DATETIME2);

我几乎没有与此相关的问题：如果用户A向用户B发送好友请求，那么从用户B到用户A的好友请求应该仍然有效吗？我觉得应该是这样，让我知道是否有更好的方法来处理这个问题？

一旦用户b批准用户朋友请求，将用户数据存储在名为friends表的单独表中是否是个好主意？并且一旦用户B批准用户A请求，则需要将两个记录插入到包含用户A的col1和包含用户B的col2的friends表中。同时我们还应该在col1中插入用户B而在col2中插入用户A的记录。？或者两个记录是不必要的？

Answer 1

一旦用户b批准用户朋友请求，将用户数据存储在名为friends表的单独表中是否是一个好主意？

不，在数据库中复制数据几乎不是一个好主意。您可以获得异常，其中两个地方的相同数据具有两个不同的值。哪个值是正确的值？

这是维持关系的一种方式

User
----
User ID
User Name
...

Friend
------
User ID 1
User ID 2
...

在Friend表中，主键是（User ID 1，User ID 2）。您还将拥有一个唯一索引（用户ID 2，用户ID 1）。如果你想为每个关系设置一行或两行，这取决于你。

一行表示您必须使用UNION执行两个SELECTS。一个SELECT使用主键，一个SELECT使用唯一索引。

两行表示使用主键执行SELECT。

您与FriendRequest表具有相同的一行/两行选择。

FriendRequest
-------------
User ID 1
User ID 2
Status
Sent Time Stamp
Accepted Time Stamp
...

每个请求可以有一行或两行。在这种情况下，我更喜欢这一行，因为我可以确定哪个用户发起了朋友请求。

Answer 2

我将从Facebook的一些例子中回答。

如果用户A向用户B发送了好友请求，则该好友请求从用户B到用户A应该仍然有效吗？

不，会出现一个对话框You have already recieved a Friend Request from {name}。另外，从B的观点来看，Send Friend Request与A的链接应更改为Respond to friend request，并附带相应的代码。

将用户数据存储在名为friends ...？
的单独表中是一个好主意

不，一条记录就足够了。此外，您可以使用新列来维护状态status={blocked|friends|pending}

这就是我的想法。您是免费的，因为申请是您的。以用户身份思考。

如何在sqlserver中维护好友请求数据

2 个答案: