Facebook 之类的通知跟踪（DB 设计）

Question

我只是想弄清楚 Facebook 的数据库是如何构建用于跟踪通知的。

我不会像 Facebook 那样深入讨论复杂性。如果我们想象一个简单的通知表结构：

notifications (id, userid, update, time);

我们可以使用以下方式获取朋友的通知：

SELECT `userid`, `update`, `time`
FROM `notifications`
WHERE `userid` IN 
(... query for getting friends...)

但是，应该使用什么表结构来查看哪些通知哪些已经读过，哪些还没有？

Answer 1

我不知道这是否是最好的方法，但由于我没有从其他人那里得到任何想法，这就是我要做的。我希望这个答案也能对其他人有所帮助。

我们有 2 个表，

notification
-----------------
id (pk)
userid
notification_type (for complexity like notifications for pictures, videos, apps etc.)
notification
time


notificationsRead
--------------------
id (pk) (i dont think this field is required, anyways)
lasttime_read
userid

想法是从通知表中选择通知并加入到 notificationRead 表中，然后检查上次读取的通知和 ID > 的行。通知ID。每次打开通知页面时都会更新 notificationRead 表中的行。

我想对未读通知的查询会是这样的。

SELECT `userid`, `notification`, `time` from `notifications` `notificationsRead`
WHERE 
`notifications`.`userid` IN ( ... query to get a list of friends ...) 
AND 
(`notifications`.`time` > (
    SELECT `notificationsRead`.`lasttime_read` FROM `notificationsRead` 
    WHERE `notificationsRead`.`userid` = ...$userid...
))

上面的查询没有被检查。
感谢@espais的db设计思想

Answer 2

您可以添加另一个表...

tblUserNotificationStatus
-------------------------
- id (pk)
- notification_id
- user_id
- read_status (boolean)

如果您想保留历史记录，您可以保留 X 个最新通知并删除列表中早于最后一个通知的其余通知...

Answer 3

如果您在发出通知时发出了当时可用的所有相关通知，则可以通过将时间戳附加到可通知事件并跟踪每个用户上次收到通知的时间来简化此操作。但是，如果您处于多服务器环境中，则必须小心同步。请注意，这种方法不需要真正的日期时间戳，只需要单调增加的东西。

Answer 4

我发现这里没有人解决这样一个事实：通知通常会重复出现。即将进行的交易的通知始终是相同的，但其中包含不同的交易 ID 或日期。像这样：{您有一笔新的即将付款：@ paymentID，到期日为@ dueDate }。
将文本放在不同的表中也可以帮助

1. 如果您想稍后更改通知文本
2. 使应用程序多语言更容易，因为我可以使用语言代码对通知表进行分层并检索适当的字符串

因此我还制作了一个表对于那些抽象通知，它们只是通过中间表链接在用户下，其中一种通知类型可以多次发送给一个用户。我还不是通过外键 ID 将通知链接到用户，但我为所有通知创建了通知代码，并为这些代码的 varchar 字段建立了 full_text 索引，以提高读取速度。由于这些通知需要在特定时间发送，因此开发人员编写

NotificationService::sendNew( Notification::NOTE_NEW_PAYMENT, ['paymentId'] => 123, ['dueDate'] => Carbon::now(), 'userIdToSendTo' );

Now 也更容易，因为我的消息中将包含自定义数据，这些数据将插入到字符串中，正如您可以从提前第二个参数，然后我将它们存储在数据库 blob 中。 这是因为我想将通知与其他表解耦，因此

$values = base64_encode(serialize($valuesInTextArray));

我不想在通知表之间建立不必要的 FK 关系，这样我就可以说通知 234 附加到事务 23，然后加入和获取该交易 ID。将其解耦可以消除管理这些关系的开销。缺点是，几乎不可能删除通知，例如删除交易时，但在我的用例中，我决定，无论如何都不需要这样做。

我将在App端检索并填充文本，如下所示。诗。我正在使用某人的 vksprintf 函数（https://github.com/ WashingtonPost/datawrapper/blob/master/lib/utils/vksprintf.php），支持他！

$valuesToFillInString = unserialize(base64_decode($notification->values));
vksprintf( $notificationText->text, $valuesToFillInString )

另请注意我索引了哪些字段，因为我将按它们查找或排序

我的数据库设计如下

============================= ===

表：用户

• id (pk)

================================

表：通知

• id (pk)
• user_id (fk ，索引）
• text_id（fk-NotificationTexts表）
• values（blob）[包含值数组，要输入到文本字符串中]
• createdDateTime（DateTime）
• read（boolean）

[ClusterIndex]=>； （user_id，createdDateTime）

================================

表：NotificationTexts

• id（pk）
• text_id（唯一索引）
• text（varchar ) [{ 您有一笔新的即将付款：@ paymentID，到期日为 @dueDate }]
• note (varchar，可为 null) [开发人员注释，信息列]

Answer 5

我也在试图弄清楚如何设计一个通知系统。关于通知状态（已读、未读、已删除、已存档等），我认为它是 ENUM 的一个很好的候选者。我认为除了 READ 和 UNREAD 之外，可能还会有两种以上不同类型的状态，例如已删除、已存档、已查看、已驳回等。

这将使您能够随着需求的变化而扩展。

另外，我认为有一个字段来存储操作 URL 或链接可能是有意义的（至少在我的情况下）。某些通知可能要求或提示用户点击链接。

如果您想要不同的类型，那么拥有通知类型也可能有意义。我认为可能会有系统通知（例如验证电子邮件通知）和用户提示通知（例如好友请求）。

我认为这是一个像样的通知系统的最低结构。

users
-------------
id
username
password
email

notifications
-------------
id
user_id (fk)
notification_type (enum)
notification_status (enum)
notification_action (link)
notification_text
date_created (timestamp)

Answer 6

表格如下

User

• userId (Integer)
• fullName(VarChar)

Notification

• notificationId (Integer)
• creationDate (Date)
• notificationDetailUrl (VarChar)
• isRead (bollean)
• description (VarChar)
• userId (FK ）