Best practices for Design Document/views

query

#1

I am trying to use couchbase for an e-commerce application where I will have different types (tables in RDBMS world) like customer, address, invoice, invoiceDetails, Items, creditcard etc. So I have like 25 -30 different types of documents. In order to query these documents I created 4 views in a single design document.
Reading the documentation a bit more I learnt that all views are updated if any of the view changes in a single design document. So I am in the process of splitting the views in different design documents. Currently I have 4 design documents and each has a single view. I now need to create more views and I don’t want those views in one of the existing design documents, the simple reason is each type will have millions of records and I do not want to reindex/update all views.

So my question is how many design documents can I create, what are the disadvantages if I have a lot of design document (design document per view).


#2

Hi, N1QL would probably be a much better choice for your use case. May I ask you why you want to use views?


#3

I want to have queries like getAllCustomers, getAllActiveCustomer, getAllInvoicesWhoseAmountIsGreaterThan100, getCustomerByName etc. For example I have a view with the following key emit(customerName, AcitveFlag), null, I make the query object and then retrieve all the documents and return it to the client. I am currently using java SDK 1.4.x.


#4

You can have all of these queries automatically generated if you use Spring Data Couchbase 2 based on the SDK 2.x and Couchbase 4.x.


#5

Thanks for the info, but currently we are now on couchbase 3.x, migrating it to 4.x will take some time.

Back to my original question what is the disadvantage of having more than 4 design documents. With what I have currently (couchbase 3.1 and SDK 1.4) is that the best approach.

Is there no way to achieve what I am looking for, in other words am I forced to update to the latest versions?


#6

Any response feedback would be highly appreciated.