Properly structuring a couchDB app

Use Case

• I want to serv开发者_如何转开发e multiple customers from 1 couchdb
• Each customer will have their own set of data (and a subset of child data - head office as the parent and each location as the children)
• Each customer could have different UI screens
• Within each customer different users may have different UI screens
• The system will be a couchapp and distributed globally and will use replication

The Options

• For each customer store all pages in one _design document and serve the appropriate pages based on user type (permission)

• For each customer store each page into it's own _design document

• For each customer, store all pages associated with the user permission level in one _design document so that each user type will be served from a different _design document

Also, I've read two books now on couchDB and it's still not clear the advantages of using a _design document as opposed to a normal document to serve the web pages.

UPDATE 1:

I think I will need to give a clearer example.

Company A has a head office in Bangkok with management and administrative (secretaries) staff using the app. These users will belong to different user groups and have different permissions which will provide them access to different HMTL documents (or the same template doc but serving different content via js). This company has offices in Pattaya, Phuket and Chang Mai. At each of these offices they have different user types who will have access to different parts of the app and see different versions of HTML screens. The local apps will be based on filtered replication.

This couchDB will provide this service to multiple companies structured just like Company A, all from the same db (reason being that we need to be able to aggregate data for all companies and couchDB cannot aggregate across multiple databases since views are db specific if I read correctly.) However, each master Company could have slight differences to their HTML pages from other master Companies.

So focusing on structure only, my initial idea is to do multiple _design documents, one for each master Company. In each of these _design documents we store each and every HTML page for that company (which may or may not be the same as other master companies.

Is there a better way to structure this? Do you see scaling issues when we have say 1000 master companies?

P.S. Even if we can't complete solve ACL issues directly via couchDB we can always do it ourselves so this isn't a primary concern right now.

UPDATE 2:

So after more research I see how the show functions (shows) play a role in this by using templates. It doesn't fully answer my question, so I guess, based on this, I am also wondering now if there is ever a situation where you might want to have any other HTML attachement in the _design document other than index.html?

There are two basic solutions for the situation of multiple users, each can see only a subset of the total data.

1. Use a middle web tier. This is like any other MySQL/PHP or Rails architecture. CouchDB is a data back-end. You have your own user logins and management and do everything yourself.
2. Use the CouchDB security model. It requires some learning but, hey, you aren't writing your own user and authentication code yourself. To have different data sets for different user, each user has their own database and you replicate (using a filter) only the documents the user can see.

CouchDB is directly servicing all queries from the Internet. It doesn't care if the client was a browser (Couch app), iPhone, or command-line cURL. Design documents do not affect read permissions of the database at all.

Design documents are a completely transparent and exposed thing. Nothing private should be in it. For example, it might contain template files, but the private data is in other documents.

A database can have pretty much any design document because the secret information is the other documents, only some of which replicate to the users' individual databases.