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

Question

为了在社交网络中存储朋友关系，最好有另一个包含列

relationship_id, user1_id, user2_id, time_created, pending

的表，还是应该将已确认朋友的 user_id 序列化/内爆为单个长字符串并与其他用户详细信息（如

user_id, name, dateofbirth, address

和）一起存储和facebook一样限制只喜欢5000个好友吗？

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

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

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

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

Answer 3

是的，有几种有效的方法来存储 Facebook 个人资料及其好友关系。由于数据本质上表示图形结构（个人资料作为节点，友谊作为边缘），因此最合适的存储方法围绕基于图形的数据结构和数据库。以下是最常用的方法：

图数据库 • 示例：Neo4j、ArangoDB、OrientDB • 描述：图形数据库旨在存储和查询基于图形的数据。它们为节点（配置文件）、边（连接）和属性（例如，名称、年龄等配置文件属性）提供本机支持。 • 优点： • 针对遍历关系进行优化（例如，寻找共同的朋友、最短路径）。 • Cypher (Neo4j) 等查询语言使查询关系变得直观。 • 可针对大型社交网络进行扩展。