incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Petermair <>
Subject CouchDB scenario for web application
Date Thu, 06 May 2010 09:02:30 GMT

We are currently in the planning phase of a new web application and are 
evaluating CouchDB as our data storage. The application is some kind of 
timesheet and should help customers track all the time they've spend on 
different tasks.

After reading through the online OReilly book 
( and the wiki, we are still not sure, 
how we would go about mapping our domain model to CouchDB. With 
traditional SQL databases you would use something like Hibernate which 
would map object relationships with 1:n, n:n etc sql table relationships.

Let's say I have a customer object and multiple timePacket objects for 
each customer. My first thought would be something like this:

   "_id":"customer ID",
   "name":"John Doe"

   "_id":"timePacket ID",
   "customer":"customer ID",

I would save all documents in one DB and differentiate between them 
through the "type" field. To match each timePacket to a customer, I add 
a customer field to the timePacket documents (much like a foreign key in 
RDBMS). Through views I'm then able to get all timePackets for a 
specific customer.

Is this the correct way to implement object relationships in CouchDB? 
And if not, would would be? Or is this kind of scenario not suited for 

Also .. we are thinking about creating a new database for each customer 
  - so that nobody can access data from other customers, not even by 
accident. Since the system should also scale for a large number of 
customers, does CouchDB support a large number of databases? Let's say 
we have 10.000 customers, we would then create 10.000 DBs on CouchDB 
(and obviously configure replication, views, etc. programmatically 
through REST for each one).


View raw message