javascript - 討論個通知清單和詳情的API設計

想做一個通知元件，基於MVVM，所有資料走json。清單頁帶過濾和搜尋功能。通知詳情帶上一條下一條切換。

希望能實現在無過濾和搜尋條件下時，在詳情頁內直接做到全局的上一條下一條切換；而在有過濾條件或搜尋條件時，上一條下一條在搜尋結果列表中切換。

方案1：

這是我自己想出來的方案。
在整個組件初始化時，就把本用戶下的所有通知(ID)取到本地，記到全局[store.list.all]，之後當點擊詳情頁時，前端把要點擊的條目id作為參數做ajax請求，這樣詳情頁就有當前通知id，所有通知id列表。這樣的話詳情頁就可以很輕鬆的知道上一條的id、下一條的id。
當有篩選或搜尋條件時，記到全域[store.list.filter]，方法同上。

• 優點：上一條下一條會變得非常容易實現，而且列表頁每次翻頁不需要請求資料。

• 缺點：如果這個使用者的通知清單非常長，那麼初始化和搜尋的時候，需要請求並記錄到[store.list]中的資料就會非常大，首頁速度可能會非常慢，而且效能會變糟。

方案2：

公司以前產品的方案。
列表頁做分頁查詢，每次請求使用page+row做參數，以一頁row條，查詢第page頁的方式查詢（例如page=3,row=10，就表示查詢第31-40條）。過濾和搜尋功能同樣。
之前的產品未實現上一條下一條切換。
不過按照這個思路繼續搞下去的話，大概會這樣：
無過濾搜索條件下，發送當前id作為參數，並帶上next或previous參數，這樣數據庫查詢時可以依靠select * from foo where id = ( select min(id) from foo where id > 4)這個方式去查詢。
有過濾搜尋條件下，這個就比較噁心了，自己沒想出什麼好主意，大概是從列表頁點進詳情頁時保存一下搜尋狀態（這個可以做到，返回按鈕就有保存這個狀態） ，之後上一條下一條時，除了id、next，也帶上搜尋條件做查詢。就是ajax請求api寫起來會比較噁心。

• 優點：清單頁分頁，使用者有多少通知都不怕。

• 缺點：列表頁翻頁時也要請求和查詢，查詢條件複雜，後端負擔大，詳情頁上一條下一跳的ajax請求會比較難寫。

目前就這兩種思路，各有優缺點。

大家還有沒有其他思路？

回覆內容：

想做一個通知元件，基於MVVM，所有資料走json。清單頁帶過濾和搜尋功能。通知詳情帶上一條下一條切換。

希望能實現在無過濾和搜尋條件下時，在詳情頁內直接做到全局的上一條下一條切換；而在有過濾條件或搜尋條件時，上一條下一條在搜尋結果列表中切換。

方案1：

這是我自己想出來的方案。
在整個組件初始化時，就把本用戶下的所有通知(ID)取到本地，記到全局[store.list.all]，之後當點擊詳情頁時，前端把要點擊的條目id作為參數做ajax請求，這樣詳情頁就有當前通知id，所有通知id列表。這樣的話詳情頁就可以很輕鬆的知道上一條的id、下一條的id。
當有篩選或搜尋條件時，記到全域[store.list.filter]，方法同上。

• 優點：上一條下一條會變得非常容易實現，而且列表頁每次翻頁不需要請求資料。

• 缺點：如果這個使用者的通知清單非常長，那麼初始化和搜尋的時候，需要請求並記錄到[store.list]中的資料就會非常大，首頁速度可能會非常慢，而且效能會變糟。

方案2：

公司以前產品的方案。
列表頁做分頁查詢，每次請求使用page+row做參數，以一頁row條，查詢第page頁的方式查詢（例如page=3,row=10，就表示查詢第31-40條）。過濾和搜尋功能同樣。
之前的產品未實現上一條下一條切換。
不過按照這個思路繼續搞下去的話，大概會這樣：
無過濾搜索條件下，發送當前id作為參數，並帶上next或previous參數，這樣數據庫查詢時可以依靠select * from foo where id = ( select min(id) from foo where id > 4)這個方式去查詢。
有過濾搜尋條件下，這個就比較噁心了，自己沒想出什麼好主意，大概是從列表頁點進詳情頁時保存一下搜尋狀態（這個可以做到，返回按鈕就有保存這個狀態） ，之後上一條下一條時，除了id、next，也帶上搜尋條件做查詢。就是ajax請求api寫起來會比較噁心。

• 優點：清單頁分頁，使用者有多少通知都不怕。

• 缺點：列表頁翻頁時也要請求和查詢，查詢條件複雜，後端負擔大，詳情頁上一條下一跳的ajax請求會比較難寫。

目前就這兩種思路，各有優缺點。

大家還有沒有其他思路？

方案一的致命一擊： 如果一個使用者用10W條通知。

方案二的致命一擊：不停的增加查詢條件的複雜度，對儲存壓力增加。

======

中庸方案
一次讀取N天資料（前提是N天的資料量基本上可控，否則此方案不實現）。

可靠方案
使用Elasticsearch