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

Question

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

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

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

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

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列表的数组。

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