You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Patrick Petermair <pa...@openforce.com> on 2010/05/06 11:02:30 UTC
CouchDB scenario for web application
Hi!
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
(http://books.couchdb.org/relax/) 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",
"type":"customer",
"name":"John Doe"
}
{
"_id":"timePacket ID",
"type":"timePacket",
"customer":"customer ID",
"from":"01:00",
"to":"02:00"
}
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
CouchDB?
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).
Thanks!
Patrick
Re: CouchDB scenario for web application
Posted by Niket Patel <ne...@me.com>.
Patrick,
Seems like good approach if new timepacket created frequently for each customer. 10,000 DBs would not problem, you can consider using path separator "/" in DB name so Couch will organize them in folders automatically and you never get too many folders or files under single node.
if database name is "account_3/customer_1/timepacket" then couchdb file path will be ".../couchdb/account_3/customer_1/timepacketapp.couch"
Also you can store duration in timepacket document. That save some processing each time.
Storing related document varies between use case. If each customer have 20 or less timepackets and update frequency is very less then I will store them inline in customer document.
Niket
On May 6, 2010, at 2:32 PM, Patrick Petermair wrote:
> Hi!
>
> 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 (http://books.couchdb.org/relax/) 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",
> "type":"customer",
> "name":"John Doe"
> }
>
> {
> "_id":"timePacket ID",
> "type":"timePacket",
> "customer":"customer ID",
> "from":"01:00",
> "to":"02:00"
> }
>
> 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 CouchDB?
>
> 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).
>
> Thanks!
> Patrick