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.
