CouchDB 中的上一个和下一个文档
我有一个包含带有浮点时间戳的项目的数据库。当用户访问 url /item/id/ 的页面时，应显示具有相应标识符的文档（这很简单）以及指向上一个和下一个的链接按时间顺序排列下一个文档（如果存在）。
这些链接必须是持久的，并且项目往往会根据外部条件在不同的时间戳出现和消失，因此我无法选择在 URL 中缓存这些标识符之一或两者。
现在，我正在使用按时间戳排序的视图来进行两个查询（一个降序，一个升序），以便获取上一个和下一个文档。
- 我可以用更少的请求来做到这一点吗？
- 如果对象的时间戳非常接近，我担心浮点精度会造成混乱。我怎样才能避免这种情况？
I have a database containing items with a floating-point timestamp. When the user visits a page with url /item/id/<the-id-here>, the document with the corresponding identifier should be displayed (this is easy) along with links to the previous and next documents in chronological order, if they exist.
These links must be persistent, and items tend to appear and disappear at various timestamps based on external conditions, so I have no option to cache one or both of these identifiers in URLs.
Right now, I'm using a view sorted by timestamp to make two queries (one descending, one ascending) in order to fetch the previous and next documents.
- Can I do this with fewer requests?
- I'm afraid that floating-point precision will cause mayhem if objects have very close timestamps. How can I avoid this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是否有可能以某种方式在数据库中维护每个文档的上一个/下一个文档？
这取决于您拥有的读/写比率，但在每次插入/删除时执行这两个查询可能比在每次页面视图时执行更快。
Isn't it possible to somehow maintains in the database the previous/next document for each document ?
It depends of the ratio of reads/writes that you have but it might be faster to do these two queries at each insert/delete than at each page view.
不确定您是否仍在努力解决此问题，但如果是，您可以尝试以下操作：
[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 值并返回“仅”304 Not Modified响应代码。FWIW（因为它基于 CouchDB 的 View 系统/API）。
，这也适用于 Couchbase Server 2.0 API
Not sure if you're still working on solving this, but if so, you might try the follow:
[2012, 04, 30, 03, 20, 35]?startkey=[2012, 04, 30, 03, 20, 0]&endkey=[2012, 04, 30, 03, 20, 60]toget the range of key/values in the index for the last minute (or hour, day, etc.
depending on the granularity of what you're emitting).
That would get you down to a single GET request with the trade off of a larger response size. However, if you're using the HTTP
If-Not-Match/ETagheaders and some client-side caching, you may be able to get by with a single request for a larger range of documents--caching a list for the day or week range and using that cached array/whatever for later look-ups with much "lighter" hits to the server (as it would only check theETagvalues and return "just" the304 Not Modifiedresponse code.FWIW, this works with the Couchbase Server 2.0 API as well (as it's based on CouchDB's View's system/API).
Hope that helps.