在社交网络数据库中存储朋友

Question

为了在社交网络中存储朋友关系，最好是使用列relationship_id, user1_id, user2_id, time_created, pending的另一个表，还是将确认好的朋友的user_id序列化/内爆成单个长字符串并与其他用户详细信息一起存储user_id, name, dateofbirth, address并限制只有5000个与Facebook相似的朋友？

有没有更好的方法？第一种方法将创建一个巨大的表！第二个有一列非常长的字符串...

在每个用户的个人资料页面上，需要从数据库中检索他的所有朋友，以显示类似于facebook的30个朋友，所以我认为使用单独表格的第一种方法会导致大量的数据库查询？ / p>

Answer 1

执行此操作的正确的方式是拥有成员表（显然）和第二个朋友关系表。

你永远不应该永远将外键存储在这样的字符串中。重点是什么？你不能加入它们，对它们进行排序，对它们进行分组，或者首先证明拥有关系数据库的任何其他东西。

如果我们假设Member表看起来像这样：

MemberID int Primary Key
Name varchar(100) Not null
--etc

然后你的友谊表应如下所示：

Member1ID int Foreign Key -> Member.MemberID
Member2ID int Foreign Key -> Member.MemberID
Created datetime Not Null
--etc

然后，您可以将这些表连在一起以提取朋友列表

SELECT m.*
FROM Member m
RIGHT JOIN Friendship f ON f.Member2ID = m.MemberID
WHERE f.MemberID = @MemberID

（这是SQL Server的语法，但我认为它非常接近MySQL。@MemberID是一个参数）

这总是比分割字符串和进行30次额外的SQL查询以提取相关数据更快。

Answer 2

按方法1分开表格。 方法2很糟糕，因为你每次都必须反序列化它并且不能对它进行JOINS;如果用户更改了他的姓名，电子邮件或其他属性，加上UPDATE将是一场噩梦。

确保表格很大，但您可以在Member11_id上对其进行索引，将外键设置回用户表，并且可以具有静态行大小，甚至可以限制单个用户可以拥有的朋友数量。我认为如果你做得对，它不会成为mysql的问题;即使你在关系表中打了几百万行。