On Sun, Aug 16, 2009 at 1:29 AM, Frédéric Malo<[email protected]> wrote: > For example, imagine a music database as iTunes. I would like to create a > script to query such as : > > Sort all songs by genre then album : > - with 3 or 5 stars > - artist name matching "floyd" > - duration between 5 and 8 minutes > - heard last week (perhaps another couch database, logging user actions) > - .... > > All the parameters are optional. Users can choose to filter with only 2 or 5 > parameters. Other parameters should be added.
The simple answer is "you can't get there from here", at least not like you are thinking. You have a couple of options: * Refactor each of those questions into a single view for each, with the key pointing to a list of songs that match. * As the user adds more options, you are actually adding an extra request for each view * Use the built in sorting to get the sort order * Query all the various required views and return the final result set This is following a similar pattern to the ones used by Full text search engines - you are using CouchDB to create the indexes for you, which return light-weight data that gets culled based on your requirements. Another option would be to actually put all this data into a full text engine, and use that. (Solr is a nice option here, and perhaps couchdb-lucene.) Don't be afraid to do a little more work on the systems that talk to CouchDB - often when you find yourself reaching for a Join, instead reach for multiple queries and doing the computation of the final match set yourself. Adam (I've seen a system that does just this, only with CDB indexes rather than CouchDB, do very complex queries and filtering against every hotel in America at very, very high speed.) -- Opscode, Inc. Adam Jacob, CTO T: (206) 508-4759 E: [email protected]
