在数据库中实现帖子、评论和点赞

Question

我想在Postgresql中建立一个数据库，模拟类似Twitter和Instagram的社交媒体平台。以下是我的需求：

1.用户可以创建帖子 2.用户可以点赞帖子 3.用户可以评论帖子 4.用户可以评论其他用户的评论（回复评论） 5.用户可以点赞评论

现在我知道，如果用户继续以评论形式回复其他用户，我们可以有深度嵌套的评论。我想到了几个自引用表，它们都继承自一个共同的实体表。以下是我的实现：

我知道可以“点赞”另一个人的“赞”，或者评论一个“赞”，但这并非必需。为了防止这种情况，我考虑在应用程序代码级别实施这些限制。总是最好保留选项，以防将来可能需要实现它们，对吧？

我的问题是，这是一个好的数据库实现吗？有没有使用案例和可能遇到的陷阱我没考虑到的？这个设计是否适合使用案例？

- john

Answer 1

您的基本模式结构可能适用于您提到的基本用例。我只是缺少评论和帖子之间的连接（哪个评论属于哪个帖子）。您还可以认为评论和帖子是同一类型的对象，只是通过与另一个帖子的关系（或没有关系）来区分它们。此外 - 更重要的是：

现在，您应该考虑使用图形数据库来建模社交媒体领域。正如您在模式中看到的那样，大多数数据都是表之间的链接，关系数据库实际上不擅长处理高度链接的数据。这是因为SQL查询很可能会包含许多连接，一旦您的图形达到一定的大小和深度，这可能会成为性能问题。

还可以将关系型数据库（或nosqldb）与图形数据库结合使用，在其中仅在图形内部建模链接网络，并在常规数据库中建模更多面向表的数据。

有一个流行的图形数据库示例，请参见this。

如果想了解为什么图形数据库比关系型数据库更适合建模图形，请阅读this和this。

- Oswin Noetzelmann

---

我现在使用几乎相同类型的设计。用户可以对某些内容做出反应和评论（评论也可以被反应）。但是，我没有将“可以有反应”和“可以有评论”的功能放到单个实体表中，而是将它们分开。对于每个功能，我创建一个超类型，例如“可反应”，“可评论”等。因此，我不能使子类型PK引用超类型PK，因为一个子类型可能有多个超类型。相反，我为每个功能保留另一列，例如“commentableId”，“reactableId”。您对此有任何建议吗？ - Onur Önder

@Onur Onder：我的第一个建议是在数据库设计中尽可能保持简单-不要将复杂的面向对象思想应用于其中。我通常为特定功能需求设计表格，尽可能小，并且与系统的其余部分无关。通过使用UUID作为主键和引用，我不必仅限于在列中引用一种特定类型的目标类型/表。 - Oswin Noetzelmann

我只是试图避免过多的重复，但并不想在此过程中创建一些过于复杂的系统。无论是代码重复还是复杂性最终都会导致难以维护的结构。使用UUID是一个很好的想法。我已经遵循了这个实践，并且它给了我很多自由。我将尝试保持事情更加清晰和简单。有时候这是一个难以平衡的事情。但我会尝试的。顺便说一句，谢谢你的建议！ - Onur Önder

Answer 2

当前的实现已经足够好了。

• 将帖子的赞和评论的赞分开可能会在开发中更清晰。
• 考虑关系型数据库中深度嵌套的评论对性能问题的影响（可能需要递归和/或多个连接）。您可以考虑将评论限制为深度为2（例如Facebook和Youtube的示例）。
• 更多属性：用户密码、实体创建日期等。

- josephnw

---

您能详细说明一下您的第一个观点吗？您是指将其分离出来，以便开发人员更清楚地了解他们正在做什么吗？ - john

是的，将“PostLike”和“CommentLike”分开将会更清晰，例如，如果我们需要按帖子/评论分析点赞，则查询将更简单。 - josephnw