Properly structured couchDB application

Question

Use case

• I want to serve multiple customers with 1 couchdb
• Each client will have their own data set (and a subset of child data - head office as a parent and each place as children)
• Each client may have different user interface screens.
• Within each client, different users may have different user interface screens.
• The system will be couchapp and globally distributed and will use replication.

Options

• For each client, all pages are stored in one _design document and serve the corresponding pages based on the type of user (permission)

• Each client stores each page in its own _design document

• For each client, store all pages related to the user's permission level in one _design document so that each type of user is served from another _design document

Also, I have now read two books on couchDB and it is still unclear how to use the _design document, and not a regular document to serve web pages.

UPDATE 1:
I think I will need to give a clearer example.

Company A has a head office in Bangkok with management staff and an administrator (s) using the app. These users will belong to different user groups and have different permissions that will give them access to different HMTL documents (or the same template document, but with different contents via js). This company has offices in Pattaya, Phuket and Chang May. In each of these offices, they have different types of users who will have access to different parts of the application and see different versions of HTML screens. Local applications will be based on replication filtering.

This couchDB will provide this service to several companies structured in the same way as company A, all from the same dB (the reason is that we need to be able to collect data for all companies, and couchDB cannot be combined into several databases, because the views are specific to db if I read it correctly.) However, each own company may have slight differences from its HTML pages from other leading companies.

Therefore, focusing only on the structure, my initial idea is to make several _design documents, one for each leading company. In each of these _design documents, we save each HTML page for this company (which may or may not be the same as other leading companies.

Is there a better way to structure this? Do you see scaling issues when we talk about the top 1,000 companies?

PS Even if we cannot solve ACL problems directly through couchDB, we can always do it ourselves, so now this is not the main problem.

UPDATE 2:
Therefore, after more research, I see how the functions of the show (show) play a role in this, using templates. It does not completely answer my question, so I think on this basis I also wonder if there is ever a situation when you want to have any other HTML attachments in a _design document other than index.html?

Answer 1

There are two main solutions for a situation with several users: each can see only a subset of the data.

• Use an average web tier. This is similar to any other MySQL / PHP or Rails architecture. CouchDB is a database. You have your own logins and user management and everything is done independently.
• Use the CouchDB Security Model . This requires some training, but, hey, you yourself do not write your own user and authentication code. In order to have different data sets for different users, each user has his own database and replicates (using a filter) only those documents that the user can see.

Answer 2

CouchDB directly serves all requests from the Internet. It doesn't matter if the client was a browser (Couch app), iPhone or cURL command line. Design documentation does not affect database read permissions at all.

Constructive documents are a completely transparent and open thing. There should be nothing private in this. For example, it may contain template files, but personal data is in other documents.

A database can have almost any design document, since secret information is other documents, only some of which are replicated to separate user databases.