How many design documents link Couchdb?

Question

My company uses CouchDB, and I will soon have to interact with it, so I get a cool course in it, and when I read various lessons and examples, I stumbled upon the one I did. I wonder: are many design documents emptying CouchDB?

A specific example that I read that reflects my own use case is one where the middle tier creates a new project document for each client, restricting all requests and the associated generated trees to trees.

But does this not mean that you have in the best case (from a business point of view) thousands of project documents? It occurs to me that since each of these project documents must be run for each insert, at least in order to emit nothing, this would ultimately become a serious strain on the server.

Am I missing something substantial in the design of CouchDB that makes this not a problem? Or is there a smarter way to handle this?

Answer 1

AFAIK CouchDB updates views only when results are first requested (why do they have the "deprecated views" option).

So, this type of load should not be a problem for you. But you better know the disk consumption if the views output a lot of data.

Answer 2

I probably do not recommend this approach. Consider some cases:

New client

You will create a new doc project and add it to your db. In this case, when the first view is requested from this project document, it will run all the documents in db to create the index. Therefore, each new client scans all documents.

Editing a new entry / entry

All other document changes will be performed through all functions of viewing project documents.

Alternative

Create a db for each client. One doc project in each db. Have a db master for aggregation to which all client db is replicated.