Qual è il modo migliore per archiviare i datetime (timestamp) in CouchDB?

Question

Sto pensando che le stringhe di tempo UTC come 2011-01-26 21:41:09 +0000 potrebbero essere accettabili poiché ordinano correttamente se vengono utilizzate in una chiave di visualizzazione, ma la memorizzazione del fuso orario (ad esempio 2011-01-26 16:41:09 -0500) renderebbe il documento più leggibile. La conversione della data in un intero storico sembra la meno attraente dal punto di vista della leggibilità, ma forse la migliore per le prestazioni (o fa la differenza?). Qual è la pratica consigliata qui?

Answer 1

tempo è una cosa unidimensionale. Un timestamp più fuso orario è bidimensionale, che descrive un punto nel tempo e una posizione. Le visualizzazioni del lettino sono unidimensionali (ma non il plug-in GeoCouch), quindi è consigliabile memorizzare in una zona comune (UTC).

Probabilmente il formato più a prova di futuro è una stringa che ordina naturalmente in ordine cronologico. Probabilmente il formato più conveniente è quello che JSON2 produce:

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

Answer 2

È possibile archiviare le date come mai si desidera *, è il modo in cui vengono visualizzate nelle visualizzazioni che è importante.

* Finché Date.parse() può leggerlo.

C'è una buona soluzione qui: Sorting Dates in CouchDB Views

Answer 3

Mi piace usare millisecondi dall'ultima epoca. È possibile calcolare questo fuori con:

new Date().valueOf() 

È possibile creare una nuova data da millisecondi con:

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

mi piace creare una vista in cui il timestamp (in millisecondi) è il tasto b/c l'ordinamento è estremamente facile in questo modo.

Inoltre, penso che l'utilizzo degli interi sia più efficiente delle stringhe, almeno quando si tratta di lavorare con i dati al di fuori di CouchDB.

Answer 4

Se si sta usando solo il lato Mappa di Riduzione mappa, è probabile che questi suggerimenti vadano bene. Se, tuttavia, vuoi ridurre i risultati (_count, _stats, _sum), allora ti consiglio di emettere le date come array in modo da poter utilizzare group_level.

Ad esempio, se si emette (doc.date.split ('-')) su stringhe di data formattate come "2011-02-14", è possibile restituire _count (ad esempio) per giorno, mese, e anno usando group_level = 3, 2 e 1 rispettivamente.

È possibile filtrare ulteriormente i dati aggiungendo dati non datati all'inizio del tasto. Se stavi emettendo i nomi di Twitter, ad esempio, la tua chiave potrebbe sembrare ["bigbluehat", "2011", "02", "14"] e la tua riduzione potrebbe restituire il conteggio totale di tutti i tweet per l'utente "bigbluehat" come così come le statistiche per quell'utente per giorno, mese e anno.

Se non si utilizza il lato di riduzione delle cose, è probabile che i tasti basati su stringhe stiano bene.

Answer 5

Indipendentemente dal tipo di archiviazione dei dati che utilizzo, in genere desidero un timestamp unix in questo campo come un campo, in cui includerò uno per la data di creazione e quindi un campo aggiornato che posso modificare quando il documento i cambiamenti.

Preferisco l'approccio "secondi dall'epoca" piuttosto che "millisecondi dall'epoca", semplicemente per brevità.

Math.round(new Date().getTime()/1000) fa il trucco per me.

In termini di leggibilità, voglio memorizzarlo come un numero intero per facili confronti e utilizzare il front-end per visualizzarlo in modo corretto.