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

Question

为了在社交网络中存储朋友关系，最好使用另一个包含列relationship_id、user1_id、user2_id、time_created、pending的表，还是应该将已确认朋友的 user_id 序列化/内爆为单个长字符串并存储除了其他用户详细信息（例如用户 ID、姓名、出生日期、地址）以及类似于 facebook 的仅喜欢 5000 个朋友的限制之外？

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

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

Answer 1

最正确的方法是拥有成员表（显然）和第二个朋友关系表。

您永远不应该将外键存储在这样的字符串中。有什么意义？您无法加入它们、对它们进行排序、对它们进行分组或任何其他证明拥有关系数据库的理由。

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

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

那么你的 Friendship 表应该看起来像这样：

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；如果用户更改了他的姓名、电子邮件或其他属性，那么更新将是一场噩梦。

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