感觉SF的站内提醒设计的很人性化，琢磨半天，有几个问题：
+ 通知类型的合并（回答通知、回复通知、点赞通知）
+ 通知未读数量的合并（同类型的通知，未读数量合并，10个人同一话题点赞，只算一个未通知）
+ 如果一个页面上只取20条数据，但这20条都是同类型，需要合并通知的场景下，如何设计？一合并，就只剩下一条，而且20条合并在一起也许没有问题，但如果是热门话题，1000条的回复，也是合并在一起么？
想知道这三个情况，SF是如何设计。
如果考虑到数据表拆分，这样的合并又会是如何设计？
感觉SF的站内提醒设计的很人性化，琢磨半天，有几个问题：
+ 通知类型的合并（回答通知、回复通知、点赞通知）
+ 通知未读数量的合并（同类型的通知，未读数量合并，10个人同一话题点赞，只算一个未通知）
+ 如果一个页面上只取20条数据，但这20条都是同类型，需要合并通知的场景下，如何设计？一合并，就只剩下一条，而且20条合并在一起也许没有问题，但如果是热门话题，1000条的回复，也是合并在一起么？
想知道这三个情况，SF是如何设计。
如果考虑到数据表拆分，这样的合并又会是如何设计？
对于OLTP类型的事务数据库，保存的时候不需要合并，显示时根据各种类型的通知进行统计。
回答、回复、点赞等事件是有区别的，如果用户需要这些信息，那么就必须将它们保存到数据库中。
对于数据仓库，可以根据需求对数据进行统计，但是确定保存的“粒度”是至关重要的。粒度大，细节就丢失。粒度小，数据量大。
