数据库设计，用于向用户存储通知 [英] Database design to store notifications to users

问题描述

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

我正在尝试了解如何构建数据库以存储此信息。我想出了两个可能的想法。

1. 将链接存储到通知对象，描述用户的操作类型（新的，更新等）的字段正在被通知。这使得复杂的显示代码，但它意味着我可以改变通知工作，而不是很容易。这也增加了从数据库中提取的数据，除非我使用缓存字段将相关属性的哈希转储到表中。

   
   
   
   
   
   • notifiable_type
   
   
   • notifiable_id
   
   
   • user_id
   
   
   • 动作
   
   
   • notifiable_cache（可选，存储从通知对象选择的属性的哈希值）
   
   



2. 处理像电子邮件这样的通知，只需将其保存到具有主题和消息的数据库中即可。这导致了一个简单的视图，但复杂的模型，并阻止我轻松地更改通知如何工作。

   
   
   
   
   
   • user_id
   
   
   • title
   
   
   • >
     

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

解决方案

我正在开展一个利用通知的项目，我不知道现在是否将您的或者它可能有帮助，但这是我使用的表结构：

 通知：
  -  ID（PK）
  -  recipient_id 
  -  sender_id 
  -  activity_type（'对帖子发帖'，'发送好友请求'等）
  -  object_type（'post'，'photo'等） 
  -  object_url（以HTML格式提供通知对象的直接链接）
  -  time_sent 
  -  is_unread 
  

I'm working on a literature community website. (screenshot) And I'm trying to figure out how to notify users when someone comments on something they posted to the site, when someone they are watching submissions a new literature peice, etc.

I'm trying to figure out how to structure the database to store this information. I've come up with two possible ideas.

1. Store a link to the notifiable object, a field describing the type of action (new, update, etc) that the user is being notified of. This makes for complex display code but it means I can change how notifications work rather easily. This also increase the data I need to pull from the database unless I use a cache field to dump a hash of relevant attributes into the table.

   • notifiable_type
   • notifiable_id
   • user_id
   • action
   • notifiable_cache (optional, stores a hash of selected attributes from notifiable object)

2. Treat the notifications like email and just save them to the database with a subject and message. This results in a simple view but a complex model and prevents me from easily changing how notifications work.

   • user_id
   • title
   • message

I'm looking for other ideas and comments on the two I listed above.

解决方案

I'm working on a project utilizing notifications as well, I'm not sure if you got yours sorted out by now or if it might help but this is the table structure I used:

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 

这篇关于数据库设计，用于向用户存储通知的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！