couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kai Griffin <k...@resourceandrevenue.com>
Subject Re: Sorting dates in CouchDB
Date Mon, 08 Oct 2012 23:44:33 GMT
On 08/10/2012 22:14, Mark Hahn wrote:
>> so I've always just felt more comfortable having them stored as dates to
> begin with so there's no additional conversion process to extract those
> year, month, etc values.
>
> Whether you use numbers or strings it still needs to do a conversion from
> json (a string) to a Date object.  For that matter it might be slower to
> convert from the JSON number in a string to a Date than from a string to a
> Date.  I have no idea of course.
>
> I just realized I was thinking of code in the client.  Using a number for a
> key lookup is probably faster.  I wonder if Couch stores the JSON as a
> string in the DB or converted to binary.
>

First of all, having now browsed this topic of dates-as-strings vs 
dates-as-long-ints a little bit, I didn't realise until now that storing 
full date strings in this context is fairly commonplace, even in text 
books.  It suggests that many of my assumptions about performance might 
be ill-founded.  I still struggle to see how "new Date(dateString)" 
could be as speed-efficient as "new Date(milliseconds)" within a map 
function, but this only impacts view creation (and only if you actually 
have to instantiate a date object like that), so the penalty is paid 
only once per document (but in my case this is tens of millions of 
documents, so it still might be a big enough penalty to worry about).

I guess as a storage-space miser (and admittedly also on a philosophical 
level), I still personally prefer that dates, representing as they do 
milliseconds, remain numbers in storage, and  come to life only 
fleetingly as long, readable strings at run-time on the client-side.  
Even if the numeric version is stored as a string internally within 
JSON/couch, it's still less than half the size of the equivalent full 
date string.  This doesn't help with reading Futon or log files, 
admittedly.  In my own case, I have several different kinds of date-time 
values in each document, and over 30 million documents, growing daily - 
the storage space difference between numeric and full-string versions of 
dates would definitely be significant.


Mime
View raw message