¿Cuál es la mejor forma de almacenar las fechas (marcas de tiempo) en CouchDB?

Question

Creo que las cadenas de tiempo UTC como 2011-01-26 21:41:09 +0000 podrían estar bien ya que se ordenan correctamente si se usan en una clave de vista, pero almacenar la zona horaria (por ejemplo, 2011-01-26 16:41:09 -0500) haría que el documento fuera más legible. La conversión de la fecha a un entero de época parece ser la menos atractiva desde el punto de vista de la legibilidad, pero tal vez sea mejor para el rendimiento (¿o hace una diferencia?). ¿Cuál es la práctica recomendada aquí?

Answer 1

tiempo es una cosa de una sola dimensión. Una marca de tiempo más zona horaria es bidimensional, que describe un punto en el tiempo y una ubicación. Las vistas de sofá son unidimensionales (pero no el plugin de GeoCouch), por lo que es sensato almacenarlas en una zona común (UTC).

Probablemente el formato más resistente al futuro sea una cadena que se ordena naturalmente en orden cronológico. Probablemente el más conveniente tal formato es lo JSON2 salidas:

> a = new Date(); 
Thu Jan 27 2011 18:40:52 GMT+0700 (ICT) 
> JSON.stringify(a) 
"2011-01-27T11:40:52.280Z" 

Answer 2

Puede almacenar sus fechas como quiera *, es la forma en que las imprime en sus vistas lo que es importante.

* Siempre y cuando Date.parse() pueda leerlo.

Hay una buena solución a este problema: Sorting Dates in CouchDB Views

Answer 3

me gusta usar milisegundos desde la última época. Puede resolver esto con:

new Date().valueOf() 

Puede crear una nueva fecha de milisegundos con:

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

Me gustaría crear una vista en la que la marca de tiempo (en milisegundos) es la llave B/C la clasificación es súper fácil de esa manera.

Además, creo que el uso de enteros es más eficiente que las cadenas, al menos cuando se trata de trabajar con datos fuera de CouchDB.

Answer 4

Si solo está utilizando el lado del mapa de Map reduce, estas sugerencias probablemente estén bien. Sin embargo, si desea reducir los resultados (_count, _stats, _sum), le recomiendo que emita las fechas como matrices para que pueda usar group_level.

Por ejemplo, si emite (doc.date.split ('-')) en una cadena de fechas formateada como "2011-02-14", entonces podría devolver _count's (por ejemplo) por día, mes, y año usando group_level = 3, 2 y 1 respectivamente.

Puede filtrar los datos añadiendo datos que no sean de fecha al principio de la clave. Si estuvieras sacando nombres de Twitter, por ejemplo, tu clave podría verse como ["bigbluehat", "2011", "02", "14"] y tu reducción podría devolver el recuento total de todos los tweets para el usuario "bigbluehat" como así como las estadísticas para ese usuario a lo largo del día, mes y año.

Si no está utilizando el lado reducido de las cosas, las claves basadas en cadenas probablemente estén bien.

Answer 5

No importa qué tipo de almacenamiento de datos utilizo, normalmente quiero una marca de tiempo Unix allí como un campo, en el que incluiré uno para la fecha de creación, y luego un campo actualizado que puedo cambiar cuando el documento cambios.

Prefiero el enfoque regular de "segundos desde época" en lugar de "milisegundos desde época" simplemente por brevedad.

Math.round(new Date().getTime()/1000) hace el truco para mí.

En términos de legibilidad, quiero almacenarlo como un número entero para facilitar las comparaciones, y usar el frente para que se vea bien.