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

我也在处理一个项目,它也在利用通知,我不确定您现在是否已将您的项目整理好,或者是否有帮助,但这是我使用的表结构:

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 

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)

这个怎么样?你可以把它和评论或者回复评论混合在一起。

我认为你的第一个选择是最好的。它比第二个更具可伸缩性,并且它使您能够非常容易地查找特定类型的每个通知。您将要保存的数据总量也将更小,因为您不必将整个消息保存给用户。
如果你注意如何编写和设计代码,我认为不会太复杂。

但是,如果通知不太可能更改,那么第二个选项可能更容易实现。

但是,如果用户在站点上时不需要实时更新这些通知(例如,如果它们在登录时显示,或者通过电子邮件发送),那么您可以在用户登录时查询一次,并缓存通知。如果您要不断地实时查询此信息以检查新通知,并且您有很多用户,那么随着表的增长,这最终会给您带来麻烦。您可以通过为不同的通知类型设置单独的表来对其进行切分,或者按user_id进行划分,但这只会达到目前的效果。

你还需要确保你修剪桌子。您可能需要添加一个标志来指示用户已经看到了通知,但理想情况下,一旦他们看到通知,您就可以删除它,这样可以使表保持较小。

另一种方法是将通知保留在rdbms之外。例如,如果可以接受丢失通知的可能性(例如,如果服务器停机),请考虑将通知保存在memcached中。或者看看Redis( http://code.google.com/p/redis/ ),这将使这个问题变得非常简单——存储通知,并为每个用户创建一个集合,就快完成了。

只是一些想法,希望有用。

我最近在一个iOS应用程序的Rails后端完成了这项工作,基本上使用了(2)带有时间戳,但存储在用户索引的Redis列表中。较弱的模式(基本上所有的东西都塞进了“消息”)让我们在开发和早期beta中进展得更快。

此外,由于通知是从Redis列表中弹出的,所以在更改格式方面,不需要担心太多的旧消息,尤其是如果可以删减“旧”消息的话。

支持已经有2种型号:

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

- user_notifications - id - user_id - notification_ids: Array[]