sql - 社交网络应用程序中友谊的最佳数据库架构

Question

我正在使用 Rails 开发一个社交网站，目前我可以想到几种实现友谊的方法(就像 Facebook 一样)。但是由于应用程序的许多功能都将依赖于应用程序的这一部分，我有点担心 promise 一个，然后意识到我可以做得更好，然后进行迁移并更改整个一件一件的事情。

如果你们能建议哪种方式最好，那就太好了。另外，如果我的架构都不够好，请随时提出新的建议

架构 1

一个包含 3 列的友谊表 -

user_id(发送请求的用户的id)

friend_id(接收请求的用户id)

待处理( bool 值以保持状态。如果请求被接受则为假，否则为真)

获取用户的所有好友

  def friends
    user_ids = Friendship.where(
      '(user_id = :id OR friend_id = :id) AND pending = false',
       id: self.id
    ).pluck(:user_id, :friend_id)
     .flatten
     .uniq
     .reject { |id| id == self.id }

    users = User.where(id: user_ids)
  end

获取用户收到的所有好友请求 -

def friend_requests
  friend_ids = Friendship.where('friend_id = ? AND pending = true', self.id).all
  users = User.where(id: friend_ids)
end

我能想到的优点——

与其他架构相比，它需要数据库中最少数量的表和记录。我不确定这是否真的是一个优势，因为我听说表中的记录数不会影响性能。所以如果我错了，请纠正我。

只需要几个验证。首先，user_id 在friend_id 的范围内是唯一的。其次，user_id 不等于friend_id。

DRY 代码。接受好友请求只需要找到记录并更新单个字段( bool 值 - 待定)。取消好友关系只需要找到记录并删除它

我能想到的缺点-

User.friends 和 User.friend_requests 不是即时加载的，因为它们实际上不是 ActiveRecord 关联。从长远来看，这可能是主要放缓的一个点，尤其是搜索功能，我希望通过一些共同的 friend 对结果进行排名。

架构 2

两张 table 。一种用于交友，一种用于 friend 请求——
友谊会像——

user_id(好友中的一位用户的 ID)

friend_id(好友中其他用户的id)

好友请求表也将像 -

user_id(好友中的一位用户的 ID)

friend_id(好友中其他用户的id)

要获得用户的所有 friend -

has_many :friendships,
  class_name: "Friendship",
  foreign_key: :user_id,
  primary_key: :id

has_many :friends,
  through: :friendships,
  source: :friend

获取用户的所有好友请求 -

has_many :friend_requests,
  class_name: "FriendRequest",
  foreign_key: :friend_id,
  primary_key: :id

我能想到的优点是——

User.friends 和 User.friend_requests 是可预加载的。这可以在很多地方提高性能，我在单个查询中急切加载一堆用户的 friend ，而不是一遍又一遍地访问数据库并执行 User.friends

我能想到的缺点是——

重复的友谊条目。为了使 User.friends 关联正常工作，我必须为单个friendhsip 创建 2 个条目。

| id  | user_id | friend_id |  
-----------------------------
|  1  |   15    |    30     |
-----------------------------
|  2  |   30    |    15     |
-----------------------------

这将需要复杂的验证，例如:如果第 1 行存在，则验证第 2 行的存在(在上面的示例中)。和许多其他人

建立友谊会很复杂。这将需要

从好友请求表中删除条目

在 friend 表中创建 2 行

我知道这听起来并不是一个真正的劣势，但对我来说，在创建/删除 3 个相互依赖的条目时，似乎很多地方都可能出错

我想最后这个问题归结为 -

与更多条目(架构 2)相比，数据库(架构 1)中的条目数量较少(一半)是否具有显着优势？

和

一个友谊有 2 个条目有多糟糕？ (架构2)

Answer 1

我会推荐第二个模型， friend_request 和 friendship 的单独表。虽然这些表目前可能包含完全相同的数据，但随着时间的推移，我预计它们会有所不同。

以下是可能发生的一些可能方式:-

你想让他们随好友请求一起发送消息(“嘿，记得我在学校”)

您决定要保留有关好友请求的统计信息，例如发出请求的时间

您决定在数据库中保留被拒绝的好友请求(一旦被拒绝就不允许进一步的请求)

因为它们是不同的东西，所以您应该创建不同的表而不是重载单个表。创建一个表并不难。

你应该在表格中放两行，代表关系的两个方向吗？这是规范化与性能的问题。

规范化的答案是只包含一行。这个型号:

更容易更新/插入/删除，因为只有一行需要担心

查询更困难且更慢，因为您需要从两个方向进行查询

非规范化的答案(因为存储了重复的数据)是包括两行:这个模型:

更难更新/插入/删除，因为有两行保持同步

查询速度更快，因为您可以仅从一个方向进行查询