View best practice for data search


#1

Good afternoon Couchbase gurus.
I would like to have your opinion on the best practice to fetch a subset of data that requires to be sort, filtered and paged to be fit into a data grid.
The data represents a few object type, each with different properties to be sort.
I can create a view for every data type and every column that need to be sort, or a single view for every data type with an array of values for the key. I think creating too many views can become a problem since Couchbase have to rebuild their index every time data gets written whereas I do not know how good of a practice (or how functional it is, I didn’t test it yet) it is to have an array of keys and then filter on only one value.
I do not want to use N1QL for this, we ratter stick to direct document fetch and use views as little as possible to maximise efficiency.

Thanks


#2

There’s already a question on the forums that seems to partially answer this. Asking there may prompt more answers :slightly_smiling:

Otherwise from the Couchbase documentation::

'a view is not a query, it’s an index. Views are
persistent, and need to be updated (incrementally) whenever documents
change, so having large numbers of them can be expensive. Instead, it’s
better to have a smaller number of views that can be queried in
interesting ways. ’

I’d love to know about those interesting ways myself , the full doc::
http://developer.couchbase.com/documentation/mobile/1.1.0/develop/guides/couchbase-lite/native-api/view/index.html


#3

Thank you for your input.
For the moment we decided to go with multiple views, we have 10 for this purpose, for a total of 11 views in the system. Each of the view remits only one column, this is to allow “wildcard filtering” on string column types. Drawback to this is that the filter only works on 1 column at a time, and that many views are required.
We were initially working with List documents, containing every key for a given data type, but moved away from that approach since we have several thousands of entries for most data types and it really hurt performances.

I will update this post if I find out a better approach to our problem.