I think I'll just emit every half hour. I can't do ranges easily, because another query needs to ask for "everything playing on all of a user's stations at 10:00". I have to use the "keys" post for that, which doesn't take ranges.
Right now we're emitting the data we need for that (above) query as the value for that view. I was mostly worried about size because we're emitting so much data. Would it be much slower to emit null and use include_docs? That would save a significant amount of disk space, right? On Mon, Mar 1, 2010 at 9:53 AM, Brian Candler <[email protected]> wrote: > On Mon, Mar 01, 2010 at 09:30:24AM -0700, Sean Clark Hess wrote: > > We have a database full of tv listing information. I want to write a view > > that will let me say "What is playing on ESPN at 14:45?" One way I can > > accomplish this is to emit the show multiple times, on the half hour, and > > then only ask what is playing at each half-hour interval. This is no > ideal, > > because it makes my view bigger (and this table is already huge). > > > > Can anyone think of a better idea? I'm willing to change how the objects > are > > stored if that would help. > > > > *Event Database Objects* > > { "network": "ESPN", "date":"2010-02-28", "time":"14:30", "duration" : > > "01:25" } > > If you know that no show is longer than 3 hours, then just query for all > shows on ESPN which start between 11:45 and 14:45. > > If your view design emits [channel, date, time] then this is just a > startkey/endkey query - and if you do this with descending=true then you'll > probably get the program you want first, and can ignore the remainder. If > you get nothing, then repeat the query with a longer period. > > Sometimes a multi-key fetch is helpful. e.g. if programmes always start on > 5-minute boundaries you might get away with > > {"keys":[["2010-02-28","14:45","ESPN"], > ["2010-02-28","14:40","ESPN"], > ["2010-02-28","14:35","ESPN"], > ..]} > > But in this case, emitting the keys to allow a single startkey/endkey would > be more efficient. > > You might be able to shrink the view by parsing the date and time and > emitting a number: > > js> Date.parse("2010/02/28 14:45") > 1267368300000 > > This is the number of milliseconds since Jan 1 1970, and should take 8 > bytes > (double-precision float). Beware time zone issues of course. > > HTH, > > Brian. >
