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

Question

我正在开发一个文学社区网站。 (screenshot) 我正试图弄清楚当有人在他们发布到网站上的内容时，当有人在观看他们提交的新文学作品时如何通知用户，等等。

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

1. 存储一个指向通知对象的链接，一个描述用户被通知的操作类型（新、更新等）的字段。这会产生复杂的显示代码，但这意味着我可以相当轻松地更改通知的工作方式。这也增加了我需要从数据库中提取的数据，除非我使用缓存字段将相关属性的散列转储到表中。

   • notifiable_type
   • notifiable_id
   • user_id
   • 动作
   • notifiable_cache（可选，存储来自可通知对象的选定属性的哈希）

2. 将通知视为电子邮件，然后将它们与主题和消息一起保存到数据库中。这导致了一个简单的视图，但一个复杂的模型，并阻止我轻松更改通知的工作方式。

   • user_id
   • 标题
   • 留言

我正在寻找关于我上面列出的两个的其他想法和 cmets。

Answer 1

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

但是，如果通知不太可能更改，则第二个选项可能更易于实施。

Answer 2

我不完全确定 #1 中的“操作”字段是什么意思，但如果我正确理解您的需求，您实际上是希望用户订阅通知队列，对吗？这些通知是打算通过电子邮件发送给用户，还是仅在用户登录时显示，还是两者兼而有之？

我很想将其真正视为一个队列，您在其中“发布”通知，并且用户“订阅”任何具有与其相关联的 user_id 的通知。在关系模式中，您可能确实希望使用 #1 之类的东西，其中您有一个类型的通知，与用户相关联。当然，在 user_id 上建立索引以确保您可以快速收到他们的通知。如果你要查询很多，缓存你需要的任何东西来显示是很有意义的，这样你就不必加入任何其他表——这是假设显示数据在通知已“发送”。

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

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

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

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

Answer 3

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 4

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

此外，由于通知已从 Redis 列表中弹出，因此就更改格式而言，无需担心太多旧消息，尤其是如果您可以修剪“旧”消息。

Answer 5

我也在做一个使用通知的项目，我不确定你现在是否已经解决了你的问题，或者它是否有帮助，但这是我使用的表结构：

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 6

支持已有2个型号：

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

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

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

所以一个通知可以显示给许多用户，用户可以很容易地删除一个通知或添加新的通知，对其他用户没有影响。