Couch DB - Complex Keys And View Redundancy

Question

Attempting to keep this question as simple as possible... I'm currently thinking about using two (Couch) database views.

The signature of the first one looks a little like this;

{[username, group], value}

Which I can query with - startkey=[username]&endkey[username,{}]

...

The second of the two views will look like;

{[group, username], value}

Which I can similarly query with - startkey=[group]&endkey[group,{}]

Afaik, I cannot query a view with - startkey=[{},propertyName]&endkey[{},propertyName] - which is why I feel I need two views. The problem though, is how cumbersome it feels to create two views with keys that look so similar. The big advantage, of course, is that one of the two views will give me a simple, intuitive search for usernames, and the other will do the same for groups.

Both groups, however, will allow me to use a reduce function, to identify unique usernames in each respective group.

TLDR?

Can I use just one view to uniquely identify the number of users in each group, and alternatively use either the key 'group' or 'username' properties to query it?

ierceg ierceg · Accepted Answer · 2014-02-28T12:16:31

No, you can't because the B-tree underlying the views is sorted by the keys comprising the index from the first to the last and hence doesn't permit to search by secondary, tertiary and so on keys unless the keys in front of it are also present. This is similar to adding indexes in RDBMS as the same B-tree structure underlies those. In RDBMS for an index to be used by a query, you must include at least the first key of the index. Doing a query without the first key would result in table scan (assuming no better indexes are present) whereas "querying" a CouchDb view in such a way simply results in no results. So CouchDb's views are explicit indexes without the fallback on doing a scan of all documents.

In my experience when working with CouchDb it feels like there is a built-in tendency to proliferate the views but in reality it just forces us to really think about the searches as there is no built-in fallback.

Couch DB - Complex Keys And View Redundancy

1 Answers