社交网络的 SQL 建模追随者/追随者关系

Question

我正在为我的网站构建社交图。用户将创建关系(形式为跟随者/被跟随者)，其中每一方都可以独立地跟随另一方。我的用户表如下所示:

Users table
 - UserId (PK, Auto-incrementing integer)

考虑如何对此建模，我想出了几种替代方案，例如:

(a) 一个表格将每个“跟随”操作作为单独的行保存。

Relationships table
 - FollowerId (FK to Users.UserId)
 - FollowedId (FK to Users.UserId)

这有一个缺点，即给许多用户，它会创建大量的行。

(b) 一个表格以 CSV 或其他结构形式保存了每个用户所关注的用户列表:

Relationships table
 - FollowerId (FK to Users.UserId)
 - FollowingUsers (e.g. 2,488,28,40)

这样做的缺点是查询会复杂得多(而且成本高？)。我还必须保持字符串值的顺序等...

(c) 每行一个关系，其中用户可能位于关系的任一“侧”:

Relationships table
 - Party1Id (FK to Users.UserId)
 - FollowingParty2 (boolean)
 - Party2Id (FK to Users.UserId)
 - FollowingParty1 (boolean)

这比 (a) 节省了行，但查询更复杂，因为用户可能是任何一方。

(d) 将 'following' 和 'followed by' 作为列表(b)

Relationships table
 - UserId (FK to Users.UserId)
 - FollowingUsers (e.g. 2,488,28,40)
 - FollowedBy (e.g. 2,488,28,40)

这似乎是最好的方法，但现在我必须使用事务来更新多行。

假设我希望扩展到更大的规模，尽管知道“Facebook 的问题不是我的问题” - 哪个选项或哪个其他选项是首选？

Answer 1

我会选择A。

使用其他选项将无法进行任何类型的社交图分析

使用其他选项将无法强制执行任何类型的关系约束

如果您不打算以关系方式存储数据，则无需使用关系数据库。

一种有趣的选择可能是考虑关系表模型:

关系表

关系 ID

UserId(FK 到 Users.UserId)

关系类型

您现在可以连接用户。

案例B跟随A:

添加关系Id1、UserAId、“IsFollowed”

添加关系Id1，用户BId，“IsFollowing”

case 另一个用户开始关注A:

添加关系Id1，AnotherUserId，“IsFollowing”

case 另一个用户开始关注B:

添加关系Id2，AnotherUserId，“IsFollowing”

如果您愿意，您甚至可以消除不需要的行:
A开始跟随B:

添加关系Id3、UserAId、“IsFollowedAndIsFollowing”

添加关系Id3，用户BId，“IsFollowedAndIsFollowing”

删除关系Id1，用户BId，“IsFollowing”