Want to implement a notification system like segmentfault.
Now there are three models, one is user, one is article and one is event.
After user pays attention to an article, an event about the article will have a notification sent to all users who pay attention to it.
Now think of three options:
One is to make an array of events under an article, while user has an array of articles that he cares about. every time he reads a notification, he searches for all articles that he cares about and finds out the event that occurred after the notification was pulled last time. However, it is necessary to record the time when the event was pulled last time and compare the time of the event. I feel that the reading performance is affected, but there seems to be no better solution. I do not know whether this is a common solution.
Another scheme is similar to the first one, but it looks like a SQL database. It is to build an event table separately, save the id of the article related to the event, and then search for the event that occurred after the last notification event was read when reading the notification, and the id of the article is also in the user’s attention list. Psychologically speaking, I don’t like this plan very much, because I feel that this is not the style of NoSQL.
Another scheme is quite illogical. article keeps a list of users who pay attention to it, and user keeps a list of events. After each event about an article occurs, all users in the inside of article’s attention list are written with an id of the event, so that user can directly populate his event list every time he pulls a notification. Obviously, the writing performance will be very poor after paying more attention, but the overall logic is very clear.
Let’s give some advice on how to implement this system better.
If I understand correctly, I will do this: three models user, article, notification
Each article contains an array: subscripters. Any user who pays attention to the current article will add the id of the changed user to this subscripters.
After each article is changed, the system will trigger the notification model, which will read all the subscripters in the current article and any created push data. It is then stored in the notification database with a status:”pending. “
If any user clicks on the pushed information, the entry will be changed to status:”open “in notification. if the user modifies the read push to unread push, the entry will also be changed back to status:”pending” in the modified entry.
In this way, anyone can pay attention to any article once, any article will be pushed once after change, and any user can change the push attribute at any time without changing any data in User and Article.
A little humble opinion, for reference only.