类似 Instagram 的通知数据模型

Posted 2023-03-11

【中文标题】类似 Instagram 的通知数据模型

【英文标题】：Instagram-like Notifications Data Model

【发布时间】：2017-08-08 02:27:11

【问题描述】：

我有一个（几乎）1:1 的数据模型，就像 Instagram 一样，其中有一个通知选项卡，它会告诉您一个列表：谁评论了您的帖子（包括文本），谁喜欢您的帖子，谁刚刚关注了你，谁刚刚关注了你（并且不是你关注的人）。

到目前为止，我已经规划出了我认为需要发生的事情，但我遇到了一些设计缺陷，我将在下面列出......

我的方法

通知表列： UUID（主键）by,to,notificationID（外键引用评论，like），postID（外键引用post），notificationText

跟随表列：UUID（主键）、by、to

评论表列： UUID（主键）、PostID（外键引用帖子）、文本、UserID（外键引用评论用户）

喜欢表格列： UUID (Primary Key), by, to

每次用户发出这些通知（评论、点赞、关注）时，他们还会创建一个通知对象，以便我可以查询通知表。

...请注意，“by”和“to”是执行操作的人与目标用户（即我喜欢其他人的帖子，所以它是“by”我，当前用户）。

设计缺陷：

问题是这些通知不是平等的。一条通知可以有四种不同的结果：一条评论（“某某评论了：'OMG THIS IS A COMMENT！'”），一个赞（“某某赞了你的帖子”），一个关注（“某某已开始关注你”）。

但只有评论和点赞需要显示评论或点赞的来源图片，关注只是关注。因此，通过关注，我根本不需要对帖子或关注的引用，而且我浪费了三列（notificationText、notificationID、postID）。

我在正确的轨道上吗？谢谢。

【参考方案1】：

在我看来，你提到的四个表之间没有关系。它们不共享外键引用。我看到的唯一外键引用是指向不属于这四个表之一的表。所以我会说这个模型是正确的方法

【讨论】：

“没有关系”是什么意思？在通知中，我有一个对评论的外键引用（至少因为我需要评论中的文本）？

对不起，我的错。我错过了，因为他们各自的表中也没有提到外键。即使那样，由于您在下表中没有外键，我认为您的方法没有问题。

即使通知不需要引用“like”对象和内部的notificationID，或者当它是“follow”并且通知不需要引用notificationID/postID??