Feel the SF station reminds the design is very humane, pondering half a day, there are several problems:
+ Notification type merging (answer notification, reply notification, like notification)
+ Notification of the combination of unread quantities (same type of notification, unread quantity merged, 10 people like the same topic, only one not notified)
+ If you only fetch 20 data on a page, but these 20 are the same type, how do you design a scenario that requires a merge notification? A merger, there is only one, and 20 of the merger may not be a problem, but if it is a hot topic, 1000 of the replies are merged together?
Want to know about these three situations, how SF is designed.
If you consider the data table splitting, how will such a merger be designed?
Reply content:
Feel the SF station reminds the design is very humane, pondering half a day, there are several problems:
+ Notification type merging (answer notification, reply notification, like notification)
+ Notification of the combination of unread quantities (same type of notification, unread quantity merged, 10 people like the same topic, only one not notified)
+ If you only fetch 20 data on a page, but these 20 are the same type, how do you design a scenario that requires a merge notification? A merger, there is only one, and 20 of the merger may not be a problem, but if it is a hot topic, 1000 of the replies are merged together?
Want to know about these three situations, how SF is designed.
If you consider the data table splitting, how will such a merger be designed?
For OLTP-type transactional databases, it is not required to be merged when saved, and is counted according to various types of notifications when displayed.
Answers, replies, likes and other events are different, and if the user needs this information, they must be saved to the database.
For data warehouses, data can be counted on demand, but determining the "granularity" of the Save is critical. The granularity is large and the details are lost. Small size, large amount of data.