You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Behrad Zari <be...@yahoo.com> on 2010/06/29 12:47:29 UTC

View Efficency

Dear Couchee's,
Consider a search page which has N search keys on a specific doc type and we 
should support OR-logic permutations of these search keys based on user input!
To support these we should write Views which index these N keys like: 
emit( [key1, key2,...], null )
but since view keys are ordered we can't search with this query: 
key2==value2 || key4==value4

For this to happen, we may write a view for each permutation! (multi-view 
technique)
OR
emit keys like this:

emit( [first, key1, key2,...], null )
emit( [second, key2, ...], null )

Then we have a single large view.


My question is: 
1) Which solution is more query-effective with regards to data retrieval?
2) Is there any other way to support advanced-runtime searches through permanent 
views?

--Behrad



Re: View Efficency

Posted by Patrick Barnes <mr...@gmail.com>.
As Daniel Truemper said, couchdb-lucene is what you want for any kind of 
partial matching capability. A couchdb-lucene query can also be crafted 
to match A OR B.

If you only want a straight OR match, for instance "show me documents 
where doc.author is '0102010' or '0102014'", then the simplest thing to 
do is probably to run two queries and merge client-side.

-Patrick

On 29/06/2010 8:47 PM, Behrad Zari wrote:
> Dear Couchee's,
> Consider a search page which has N search keys on a specific doc type and we
> should support OR-logic permutations of these search keys based on user input!
> To support these we should write Views which index these N keys like:
> emit( [key1, key2,...], null )
> but since view keys are ordered we can't search with this query:
> key2==value2 || key4==value4
>
> For this to happen, we may write a view for each permutation! (multi-view
> technique)
> OR
> emit keys like this:
>
> emit( [first, key1, key2,...], null )
> emit( [second, key2, ...], null )
>
> Then we have a single large view.
>
>
> My question is:
> 1) Which solution is more query-effective with regards to data retrieval?
> 2) Is there any other way to support advanced-runtime searches through permanent
> views?
>
> --Behrad
>
>
>

Re: View Efficency

Posted by Daniel Truemper <tr...@googlemail.com>.
Hi,

> Dear Couchee's,
> Consider a search page which has N search keys on a specific doc type and we 
> should support OR-logic permutations of these search keys based on user input!
> To support these we should write Views which index these N keys like: 
> emit( [key1, key2,...], null )
> but since view keys are ordered we can't search with this query: 
> key2==value2 || key4==value4
> 
> For this to happen, we may write a view for each permutation! (multi-view 
> technique)
> OR
> emit keys like this:
> 
> emit( [first, key1, key2,...], null )
> emit( [second, key2, ...], null )
> 
> Then we have a single large view.
> 
> 
> My question is: 
> 1) Which solution is more query-effective with regards to data retrieval?
> 2) Is there any other way to support advanced-runtime searches through permanent 
> views?
You should try couchdb-lucene (http://github.com/rnewson/couchdb-lucene). I think you are looking for a fulltext index. CouchDB views are not designed for this.

Daniel