tags:

views:

257

answers:

1

It seems you are unable to nest databases in CouchDB. How do people work around this limitation? For example, assume I want to create a blogging engine where each domain has a separate database. Within each database I might want a Users database, an Orders database, etc. to contain the various user documents, order documents, and so forth.

The obvious way seems to be a flat structure where the database name demarcates the artificial boundary between database nesting levels with a hyphen:

myblog.com-users
myblog.com-posts
myblog.com-comments
anotherblog.com-users
anotherblog.com-posts
anotherblog.com-comments
...hundreds more...

Another solution would be to keep the lower-level databases and mark each document with the top-level value:

users database containing a document User1, with field instance="Test" or a field domain="myblog.com"

+1  A: 

I think you misusing the term database here. There is no reason you can't the users, posts, and comments data in a single couchdb database. Your couchdb views can seperate out the user documents from the posts documents, from the comments documents.

example map function for user documents in a couchdb database:

function(doc) {
  if (doc.type = 'user') { // only return user documents
     emit([doc.domain, doc.id], doc); // the returned docs will be sorted by domain
  }
}

see View Api for ways to restrict that views results by domain using startkey and endkey with view collation.

Jeremy Wall
rcampbell
Beyond terminology, your suggestion of using Views to separate out the the user docs, post docs, and comment docs definitely jives with my idea to use a discriminator key/value pair for each document. To me it just feels like a hack to have to say Post.domain = MyApp, User.domain = MyApp, Comment.domain = MyApp, etc. Lots of data duplication. In addition, it just feels wrong security-wise to be grouping all client data together. A vulnerability in the view could expose one client to another client's data.
rcampbell
Bad choice of words on my part probably. My point was that if you want to have posts comments and users all in one database that is perfectly fine. Having a database per domain is probably a good idea but if you want to collate or join the post and comments documents say then it would be easier if you kept them all in the same database.
Jeremy Wall
"but if you want to collate or join the post and comments documents" - this is a very good point
rcampbell