社交网络的架构设计建议

时间:2019-09-30 11:06:54

标签: postgresql database-design

我正在尝试为社交网络应用提出一个方案。

用户可以发布帖子,并且其中包含照片。 帖子和照片都可以具有喜欢评论。 帖子可以有多个合作者/所有者,这就是为什么我添加了“帖子参与者”表的原因。

用户可以通过在帖子文本内搜索关键字或通过帖子的标签来搜索帖子。 这就是为什么我对它们都使用 tsvector 类型,并用GiN索引类型进行索引的原因。

到目前为止,我已经提出了以下模式:

enter image description here

我的主要设计问题是:

  1. 帖子中的标签-我做的还好吗,即-将帖子的标签存储在Posts表中的一列 tsvector 中?

    我想到了另外两个想法:

    a。拥有一个单独的#标签表,例如id|post_id|tag_name,每个记录将代表每个单独的#标签。听起来效率低下,但会导致记录过多。

    b。与a相同,但“ tag_name”是代表所有帖子的主题标签的tsvector。与选项“ a”相比,这将导致表中的记录少得多。

  2. 已保存的帖子-如果我有1万个帖子怎么办,而每个帖子都会被1千个人喜欢。这将导致一千万条记录!听起来效率不高。

  3. 规范化-在我看来,表太多了,需要很多JOINS才能将整个Post对象检索给客户(以及评论,顶,照片及其评论/顶等)。 ),以及编写起来非常复杂。检索/撰写不同帖子的查询会太慢/麻烦吗?

  4. 评论-我应该像在上面的设计中那样将帖子的评论和照片的评论分开吗?或将它们组合成一张桌子?
    1. 我希望评论中包含1级回复。我是否应该在评论表中添加一列“ parent_comment_id”?

1 个答案:

答案 0 :(得分:0)

  1. 将帖子的主题标签存储在Posts表的一列tsvector中是一件好事,因为您没有在其他任何表中使用它。但是,如果您在需要联接表的任何情况下都需要标签,则最好将它们保留在另一个表中以提高灵活性。

  2. 最好保留这样的记录,因为您保留了ID的正确性。因此,它不会导致任何瓶颈。我相信您将使用CSV。

  3. 您始终可以优化查询,明智地使用联接,并确保在正确的位置使用正确的联接。

  4. 如果将帖子的评论和照片的评论分开,会更好,因为您会发现它更容易检索和存储数据。无论如何,您都可以在需要时对其进行组合。这样可以避免任何数据拥塞。

  5. 听起来不错。