Я думаю, что строки времени UTC, такие как 2011-01-26 21:41:09 +0000, могут быть в порядке, поскольку они правильно сортируются, если они используются в ключе вида, но сохранение часового пояса (например, 2011-01-26 16:41:09 -0500) сделает документ более удобочитаемым. Преобразование даты в целое число эпохи представляется наименее привлекательным с точки зрения читаемости, но, возможно, лучше всего подходит для производительности (или это имеет значение?). Какая рекомендуемая практика здесь?
Каков наилучший способ хранения datetimes (временных меток) в CouchDB?
Ответ 1
Время - одномерное. Временная метка плюс часовой пояс двумерная, описывающая момент времени и местоположение. Представления Couch являются одномерными (но не плагинами GeoCouch), поэтому сохранение в общей зоне (UTC) является разумным.
Вероятно, наиболее перспективный формат - это строка, которая, естественно, сортируется в хронологическом порядке. Вероятно, наиболее удобным таким форматом является то, что выдает JSON2:
> a = new Date();
Thu Jan 27 2011 18:40:52 GMT+0700 (ICT)
> JSON.stringify(a)
"2011-01-27T11:40:52.280Z"
Ответ 2
Если вы просто используете карту карты Карты, уменьшите, чем эти предложения, вероятно, прекрасны. Если, однако, вы хотите уменьшить результаты (_count, _stats, _sum), я бы рекомендовал испускать ваши даты в виде массивов, чтобы вы могли использовать group_level.
Например, если вы испускаете (doc.date.split('-')) строки даты, отформатированные как "2011-02-14", вы можете вернуть _count (например) в день, месяц и год, используя group_level = 3, 2 и 1 соответственно.
Вы можете дополнительно фильтровать данные, добавляя не-данные к началу ключа. Например, если вы выводили имена Twitter, ваш ключ мог бы выглядеть как [ "bigbluehat", "2011", "02", "14" ], и ваше сокращение может вернуть общее количество всех твитов для пользователя "bigbluehat" как а также статистику для этого пользователя через день, месяц и год.
Если вы не используете уменьшающую сторону вещей, тогда строковые ключи, вероятно, прекрасны.
Ответ 3
Независимо от того, какое хранилище данных я использую, я обычно хочу, чтобы временная метка unix была там как поле, в которое я буду включать один для созданной даты, а затем обновленное поле, которое я могу изменить при изменении документа.
Я предпочитаю обычный "секунда с эпохи", а не "миллисекунды с эпохи" просто для брекетов.
Math.round(new Date().getTime()/1000) делает трюк для меня.
С точки зрения удобочитаемости я хочу сохранить его как целое для простого сравнения и использовать переднюю часть, чтобы отобразить его красиво.
Ответ 4
Вы можете хранить свои даты, как вам хочется *, это то, как важно вывести их в свои представления.
* Пока Date.parse() может его прочитать.
Здесь есть хорошее решение: Сортировка дат в представлениях CouchDB
Ответ 5
Мне нравится использовать миллисекунды с прошлой эпохи. Вы можете понять это:
new Date().valueOf()
Вы можете создать новую дату из миллисекунд с помощью:
var milliseconds = new Date().valueOf();
var date = new Date(milliseconds);
Мне нравится создавать представление, где временная метка (в миллисекундах) - это сортировка b/c ключей, которая очень проста.
Кроме того, я думаю, что использование целых чисел более эффективно, чем строки, по крайней мере, когда дело доходит до работы с данными вне CouchDB.