Каков наилучший способ хранения даты и времени в CouchDB?

Question

Я думаю, что строки времени UTC, такие как 2011-01-26 21:41:09 +0000, могут быть в порядке, так как они сортируются правильно, если они используются в ключе представления, но сохранение часового пояса (например, 2011-01-26 16:41:09 -0500) сделает документ более читабельным. Преобразование даты в целое число эпохи кажется наименее привлекательным с точки зрения читабельности, но, возможно, лучше всего для производительности (или это имеет значение?). Какая рекомендуемая практика здесь?

Answer 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"

Answer 2

Если вы просто используете сторону Карты, уменьшите, тогда эти предложения, вероятно, подойдут. Однако если вы хотите уменьшить результаты (_count, _stats, _sum), то я бы рекомендовал указывать даты в виде массивов, чтобы вы могли использовать уровень_группы.

Например, если вы отправляете (doc.date.split ('-')) для строк даты, отформатированных как "2011-02-14", то вы можете вернуть _count's (например) за день, месяц и год с использованием group_level = 3, 2 и 1 соответственно.

Вы можете дополнительно отфильтровать данные, добавив данные без даты в начало ключа. Например, если вы выводите имена в Твиттере, ваш ключ может выглядеть как ["bigbluehat", "2011", "02", "14"], а ваше сокращение может вернуть общее количество всех твитов для пользователя "bigbluehat" как а также статистика для этого пользователя по дням, месяцам и годам.

Если вы не используете редуцирующую сторону, то ключи на основе строк, вероятно, подойдут.

Answer 3

Независимо от того, какой тип хранилища данных я использую, я обычно хочу использовать метку времени Unix в качестве поля, в которое я добавлю метку для созданной даты, а затем обновленное поле, которое можно изменить при изменении документа .

Я предпочитаю обычный подход «секунды с эпохи», а не «миллисекунды с эпохи» просто для краткости.

Math.round(new Date().getTime()/1000) помогает мне.

С точки зрения читабельности, я хочу сохранить его в виде целого числа для удобного сравнения и использовать внешний интерфейс для приятного отображения.

Answer 4

Мне нравится использовать миллисекунды с прошлой эпохи. Вы можете понять это с помощью:

new Date().valueOf()

Вы можете создать новую дату в миллисекундах с помощью:

var milliseconds = new Date().valueOf();
var date = new Date(milliseconds);

Мне нравится создавать представление, в котором метка времени (в миллисекундах) является ключом, так как сортировка b / c очень проста.

Кроме того, я думаю, что использование целых чисел более эффективно, чем строки, по крайней мере, когда речь идет о работе с данными вне CouchDB.

Answer 5

Вы можете хранить свои даты как хотите *, важно то, как вы выводите их в свои представления.

* Пока Date.parse () может читать его.

Здесь есть хорошее решение: Сортировка дат в CouchDB Views