CouchDB中的上一個和下一個文檔

我有一個數據庫，其中包含具有浮點時間戳的項目。當用戶訪問網址爲/item/id/<the-id-here>的頁面時，應該顯示具有相應標識符的文檔（這很容易），並且按照時間順序顯示前一個和下一個文檔的鏈接（如果存在）。CouchDB中的上一個和下一個文檔

這些鏈接必須是持久的，並且項目會根據外部條件在各種時間戳出現和消失，因此我無法在URL中緩存這些標識符中的一個或兩個。

現在，我正在使用按時間戳排序的視圖來創建兩個查詢（一個遞減，一個遞增）以獲取上一個和下一個文檔。

我可以用更少的請求來做到這一點嗎？
恐怕浮點精度會造成混亂，如果對象有非常接近的時間戳。我怎樣才能避免這種情況？

來源

2011-10-13 Victor Nicollet

是不是有可能以某種方式在數據庫中維護每個文檔的上一個/下一個文檔？它取決於您擁有的讀/寫比率，但在每次插入/刪除時執行這兩個查詢可能比在每個頁面視圖中執行這些查詢要快。

來源

2011-10-13 22:18:28

不知道如果您還在努力解決這一點，但如果是這樣，你可以嘗試如下：

輸出時間戳爲日期數組：[2012, 04, 30, 03, 20, 35]
使用?startkey=[2012, 04, 30, 03, 20, 0]&endkey=[2012, 04, 30, 03, 20, 60]到得到最後一分鐘（或小時，天等）的索引中的鍵/值的範圍，取決於所發射的粒度。
在客戶端代碼中，使用您正在尋找兄弟的文檔的時間戳，然後從數組/哈希表/字典/矢量/其他中獲取其兄弟。

這會讓你下降到一個單一的GET請求與一個更大的響應大小的權衡。但是，如果您使用的是HTTP If-Not-Match/ETag標題和某些客戶端緩存，則可以通過針對更大範圍文檔的單個請求來獲取 - 緩存一天或一週範圍的列表並使用該緩存陣列/任何用於稍後查找的命令與服務器的命中「較輕」（因爲它將僅檢查ETag值並返回「僅」

FWIW，這與Couchbase服務器一起使用2.0 API（因爲它基於CouchDB的View系統/ API）

希望對您有所幫助

來源

2012-04-30 19:34:27 BigBlueHat

CouchDB中的上一個和下一個文檔

回答

相關問題