segmentfault中站內提醒是如何合并的？

感覺SF的站內提醒設計的很人性化，琢磨半天，有幾個問題：
+　通知類型的合并（回答通知、回複通知、點贊通知）
+　通知未讀數量的合并（同類型的通知，未讀數量合并，10個人同一話題點贊，只算一個未通知）
+　如果一個頁面上只取20條資料，但這20條都是同類型，需要合并通知的情境下，如何設計？一合并，就只剩下一條，而且20條合并在一起也許沒有問題，但如果是熱門話題，1000條的回複，也是合并在一起嗎？

想知道這三個情況，SF是如何設計。
如果考慮到資料表拆分，這樣的合并又會是如何設計？

回複內容：

感覺SF的站內提醒設計的很人性化，琢磨半天，有幾個問題：
+　通知類型的合并（回答通知、回複通知、點贊通知）
+　通知未讀數量的合并（同類型的通知，未讀數量合并，10個人同一話題點贊，只算一個未通知）
+　如果一個頁面上只取20條資料，但這20條都是同類型，需要合并通知的情境下，如何設計？一合并，就只剩下一條，而且20條合并在一起也許沒有問題，但如果是熱門話題，1000條的回複，也是合并在一起嗎？

想知道這三個情況，SF是如何設計。
如果考慮到資料表拆分，這樣的合并又會是如何設計？

對於OLTP類型的交易資料庫，儲存的時候不需要合并，顯示時根據各種類型的通知進行統計。
回答、回複、點贊等事件是有區別的，如果使用者需要這些資訊，那麼就必須將它們儲存到資料庫中。

對於資料倉儲，可以根據需求對資料進行統計，但是確定儲存的“粒度”是至關重要的。粒度大，細節就丟失。粒度小，資料量大。

