Question

我正在撰写文学社区网站。（screenshot）我正在试图找出当有人对他们发布到网站的内容发表评论时，如果有人正在观看提交新文献的人，等通知用户等。

我正在试图弄清楚如何构建数据库来存储这些信息。我想出了两个可能的想法。

存储指向通知对象的链接，该链接描述了通知用户的操作类型（新增，更新等）。这使得复杂的显示代码成为可能，但这意味着我可以轻松地更改通知的工作方式。这也增加了我需要从数据库中提取的数据，除非我使用缓存字段将相关属性的哈希转储到表中。
- notifiable_type
- notifiable_id
- USER_ID
- 行动
- notifiable_cache（可选，存储来自可通知对象的选定属性的哈希值）
将通知视为电子邮件，只需将主题和消息保存到数据库即可。这会产生一个简单的视图，但是复杂的模型会阻止我轻松更改通知的工作方式。
- USER_ID
- 标题
- 消息

我正在寻找上面列出的两个想法和评论。

Answer 1

我正在开发一个利用通知的项目，我不确定你现在是否已将它们整理好，或者它是否有帮助，但这是我使用的表结构：

Notifications:  
- ID (PK)
- recipient_id
- sender_id
- activity_type ('comment on a post', 'sent friend request', etc) 
- object_type ('post', 'photo', etc)
- object_url (to provide a direct link to the object of the notification in HTML)
- time_sent
- is_unread

Answer 2

message :
-id_message(pk)
-to 
-from 
-subject
-message
-status (read,unread)

reply_message :
-id_reply(pk)
-id_message
-from
-message
-status (read,unread)

notification :
-id_user
-id_notify(pk)
-notify_type (message, or reply_message)
-notify_desc (comment/reply on your message)
-status (look,unlook)

notify_detail : (for notify, when user reply or comment more than 1)
-id_notify
-id_sender
-id_detail (input id_message, id_reply)

这是怎么回事？您可以将其与评论或回复评论混合使用。

Answer 3

我认为你的第一个选择是最好的。它比第二个更具可扩展性，它使您能够非常轻松地查找某种类型的每个通知。您将放置的数据总量也会更小，因为您不必将整个消息保存到用户如果你注意如何编写和设计你的代码，我认为它不会太复杂。

但是，如果通知不太可能发生变化，则第二个选项可能更容易实现。

Answer 4

我最近在iOS应用程序的Rails后端执行了此操作，并且基本上使用了（2）时间戳，但存储在用户索引的Redis列表中。较弱的模式（所有内容基本上都填充在“消息”中）让我们在开发和早期测试期间更快地移动。

此外，由于通知是从Redis列表中弹出的，因此就改变格式而言，并不需要担心很多旧消息，特别是如果您可以修剪“旧”消息。

Answer 5

我不完全确定＃1中的“action”字段是什么意思，但如果我理解你的需要，你实际上是想让用户订阅一组通知，对吧？这些通知是打算通过电子邮件发送给用户，还是仅在登录时显示，或两者都显示？

我很想将此视为一个队列，您正在“发布”通知，并且用户“订阅”任何与其user_id相关联的通知。在关系模式中，您可能希望使用＃1之类的内容，其中您有一个与用户关联的类型的通知。关于user_id的索引当然是为了确保您可以快速收到通知。如果您要对此进行大量查询，那么为了显示目的而缓存您需要的任何内容都非常有意义，这样您就不必加入任何其他表 - 这是假设显示数据在之后无法更改通知已被“发送”。

但是，如果这些通知不需要在网站上的用户实时更新（例如，如果他们在登录时显示，或通过电子邮件发送），那么您只需在登录时查询一次，并缓存通知。如果你要经常实时查询这个以检查新的通知，并且你有很多用户，那么随着表的增长，这最终会给你带来麻烦。您可以通过为不同的通知类型设置单独的表来对其进行分片，或者除以user_id，但这只会让您到目前为止。

您还需要确保修剪表格。您可能需要添加一个标记来指示用户已经看过该通知，但理想情况下，一旦他们看到它就可以将其删除，这将使该表保持较小。

另一种方法是将通知保留在rdbms之外。考虑将通知保留在memcached中，例如，如果丢失它们的可能性是可接受的（例如，如果服务器出现故障）。或者看看Redis（http://code.google.com/p/redis/），这会让这个问题变得非常简单 - 存储通知，并为每个用户创建一个集合，而且你差不多完成了。

只是一些想法，希望它们有用。

Answer 6

支持已经有2种型号：

- users - id - name - notifications - id - title - content

我将创建一个新模型： - user_notifications - id - user_id - notification_ids: Array[]

与user_notifications记录相关的每个用户，notification_ids是一个数组，其中包含该用户的相关通知id列表。

因此通知可以显示给许多用户，并且用户可以轻松删除通知或添加新通知，而对其他用户则无效。

用于存储通知给用户的数据库设计

6 个答案: