在 RDBMS 中为好友和追随者建模答案

【问题标题】：Modeling Friends and Followers in an RDBMS在 RDBMS 中为好友和追随者建模
【发布时间】：2010-10-14 17:52:51
【问题描述】：

我正在尝试确定在关系数据库中为记录关系建模的最佳方法。这是经典的朋友/关注模式：

~~~~

一个用户可以有零到多个朋友。
一个用户可以有零到多个关注者。

朋友和关注者都是用户自己。

~~~~~

对此建模的最佳方法是什么？

谢谢！

【问题讨论】：

标签： database-design data-modeling rdbms

【解决方案1】：

用户（UserId，...）
订阅（订阅者、发布者）
友谊（FirstUser，SecondUser）

CREATE TABLE Users (
    UserID int not null primary key,
    ...
)

CREATE TABLE Subscription (
    Subscriber int not null references Users(UserID),
    Publisher int not null references Users(UserID),
    constraint ck_NotEqual check (Subscriber <> Publisher)
)

CREATE TABLE Friendship (
    FirstUser int not null references Users(UserID), 
    SecondUser int not null references Users(UserID),
    constraint ck_Order check (FirstUser < SecondUser) -- since friendship is reflective
)

【讨论】：

既然 A 是 B 的朋友，B 也是 A 的朋友。我们可以记录这两个关系，也可以只保留一个。有了这个检查约束，我们强制第一个用户的 ID 总是小于第二个用户的 ID，所以我们总是可以知道如何检查友谊并且不会有欺骗。
在这个定义下，没有互惠的“可能成为朋友”是“追随者”？否则，我可能会保持 Friendship 表不对称：一个条目将记录 UserA 将 UserB 视为朋友，而单独的条目将记录 UserB 将 UserA 视为朋友。
@Jonathan：我同意您需要能够存储尚未接受的“朋友邀请”。也许另一个表Invitations 是定向的，包括邀请日期（以防它需要过期）等。一旦收件人接受，它就会移动到Friendship 表。
每个友谊解决方案两行有优势，但是在类似的社交网络项目中工作过，IMO 这种处理情况的方式问题要少得多。
我注意到你不能关注自己，例如 Twitter 就有效地强制执行了这一点。但是，我明白为什么您可能不想在数据库中处理它。