使用PHP和MySQL的通知/新闻提要

我一直在开发一个复杂的PHP系统，该系统包含社交网络理念中的元素，但只针对一个封闭的群体。我有几个模块、照片和视频库、每个模块和子模块的完整评论系统、私人消息、带有GUI的个人电子邮件等等

我的问题是，无论我如何努力，我似乎都无法有效地为通知和新闻提要部分设计后端，就像facebook所拥有的那样。这些模块基本上是事件驱动的，因此将它们连接到通知系统应该不会有问题。希望集体集思广益能解决我的问题

我将在这篇文章中只讨论我对通知部分的担忧（如果我也包括新闻提要，这篇文章将变得非常冗长和混乱）

这是我的第一个MySQL表草稿

notificationID Primary key notificationModule Module type foreign key - photo, video, comment, message notificationConstructor Foreign key of the element (which is of type "notificationModule") that triggered the creation of this notification notificationUser The user that this notification is aimed towards notificationTime Time at which the notification was created notificationFlag Notification has been read flag 通知ID 主键 通知模块 模块类型外键-照片、视频、评论、消息 通知构造函数 触发创建此通知的元素（类型为“notificationModule”）的外键 通知用户 此通知针对的用户 通知时间 创建通知的时间 通知旗 通知已被读取标志 可能的问题/冲突

• 一个用户对两个不同用户已经评论过的照片发表评论会触发三次通知吗？一个用于照片上传者，一个用于每个评论者？（影响通知用户）
  • notificationTime是创建时间。在上述问题之后，我们是否应该创建一个新的通知？此字段应该被notificationUpdateTime替换，或者可能存在于它旁边

我的目标是降低代码复杂性和提高数据库效率。试图将数据库层与代码层分开让我对网站的这一部分感到困惑：(

---

我对所有的问题和想法都持开放态度。

休息几天后，我改变了对新闻提要和通知系统的思考方式。我采取的方法是，每个事件（评论、标签等）触发一个关于两个用户的通知，一个是演员，另一个是通知所针对的用户（例如一个标记和一个被标记）。另一部分的新闻提要将从通知条目中获取一个合理的最近条目（假设它不是私有的，例如私有消息），并构建一个提要。这可能会对数据库造成压力，但我认为对于100（最大值）的情况不会有问题用户。感谢您的输入（Ryan:）

有两种方法可以访问新闻源：

• 发散
• 读时展开

您正在使用写时扇出的方法。在这种情况下，您将为每个相关用户生成一个新的单独活动

这种方法可能会很快崩溃，特别是如果您允许用户拥有无限数量的追随者。每当发生频繁的活动时，您必须为数据库中每1000多名追随者保存一个新条目

当您添加组和不同类型的观众时，事情会变得更加复杂。如果您现在只想向组A中的人广播活动，而不向组B中的人广播活动（例如，您创建了一个状态并想限制观众），该怎么办？如果您希望向A组和B组广播，但A组和B组中都有用户不希望接收同一活动两次，会发生什么情况？如果您希望在创建活动后更改活动的可见性，该怎么办

这在写的时候是不可能的，或者至少是非常困难的。这就是为什么我更喜欢后者——读的时候是扇出的

考虑这一点：

用户有一组与其id关联的新闻源频道。这些频道的形式为

{{object\u name}:{{{object\u id}}

。您可以为新闻源和通知设置单独的频道集，这样您就可以取消对一个对象的通知，而无需将其从新闻源中删除

当用户注册从对象接收更新时，他们正在将与该对象关联的频道添加到频道列表中。您可以使用简单的Redis集。例如，如果我加入事件#1，我会将

事件：1

添加到频道列表中

当属性在事件#1上更改时，新活动只创建一次。此活动有一个名为“观察者”的字段，该字段是它可见的通道的名称。在这种情况下，观察者是“事件：1”

当用户提取他们的活动提要时，他们首先获取他们订阅的频道列表。然后，他们检索观测者在其频道列表中的所有活动提要项

同时

---

我只是不确定如何将其转换为通知系统。使用“读取时扇出”方法，我有一组通知通道，如上所述。当对象上的属性更改时，我会向数据库写入一个新的通知，所有订阅的用户都会收到该通知。唯一的问题是：如何读取通知在用户对用户的基础上？我还没有弄清楚这一部分。

我只是想确定我清楚你在问什么。你是否建议将数据库用作一种通知队列？换句话说，让事件将通知放入表中，然后使用一个单独的脚本或进程来使用它们，从表中删除它们，等等d交付？如果是这样，这似乎是解决问题的一种合理有效且可扩展的方法。是的，这正是我的建议。尽管我担心的是处理通知的脚本的效率。最好是使用一个脚本，根据数据库中的条目查找用户要通知的内容，还是简单地使用m将这些通知直接针对一个用户，这意味着插入10个