Предыдущие и следующие документы в CouchDB

Question

У меня есть база данных, содержащая элементы с меткой времени с плавающей точкой. Когда пользователь заходит на страницу с URL /item/id/<the-id-here>, должен отображаться документ с соответствующим идентификатором (это легко) вместе со ссылками на предыдущий и следующий документы в хронологическом порядке, если они существуют.

Эти ссылки должны быть постоянными, и элементы имеют тенденцию появляться и исчезать в различные временные метки в зависимости от внешних условий, поэтому у меня нет возможности кэшировать один или оба этих идентификатора в URL-адресах.

Прямо сейчас я использую представление, отсортированное по отметке времени, чтобы сделать два запроса (один по убыванию, один по возрастанию), чтобы получить предыдущий и следующий документы.

• Могу ли я сделать это с меньшим количеством запросов?
• Боюсь, что точность с плавающей точкой вызовет хаос, если объекты имеют очень близкие временные метки. Как я могу избежать этого?

Answer 1

Не уверен, что вы все еще работаете над решением этой проблемы, но если это так, вы можете попробовать следующее:

1. Вывести метку времени в виде массива даты: [2012, 04, 30, 03, 20, 35]
2. Используйте ?startkey=[2012, 04, 30, 03, 20, 0]&endkey=[2012, 04, 30, 03, 20, 60] для получить диапазон ключа / значений в индексе за последнюю минуту (или час, день и т. д.) в зависимости от степени детализации того, что вы излучаете).
3. В клиентском коде используйте временную метку документа, для которого вы ищете братьев и сестер, затем получите его братьев из массива / хеш-таблицы / словаря / вектора / чего угодно.

Это привело бы вас к одному GET-запросу с компромиссом большего размера ответа. Однако, если вы используете заголовки HTTP If-Not-Match / ETag и некоторое кэширование на стороне клиента, вы можете обойтись одним запросом для большего количества документов - кэширование списка на день или недельный интервал и использование этого кэшированного массива / что угодно для последующих поисков с гораздо более «легкими» попаданиями на сервер (так как он будет проверять только значения ETag и возвращать «просто» код ответа 304 Not Modified.

FWIW, это работает и с API Couchbase Server 2.0 (так как оно основано на системе / API View CouchDB).

Надеюсь, это поможет.

Answer 2

Разве нельзя как-то вести в базе данных предыдущий / следующий документ для каждого документа? Это зависит от соотношения чтения / записи, которое у вас есть, но эти два запроса могут выполняться быстрее при каждой вставке / удалении, чем при каждом просмотре страницы.