couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric B <>
Subject How to implement multiple-tables/collections using CouchDB?
Date Thu, 11 Sep 2014 14:19:21 GMT
I've been reading up on CouchDB and am very confused as to its application
in a real world web application.  I can see it's benefit on a subset of
data, but as a primary DB for a web application, I can't say that I can see
how to do things.

Coming from my RDBMS background, I would build a basic shopping cart web
app with a bunch of tables:
 - users
 - permissions
 - items
 - inventory
 - clients
 - orders
 - etc...

I realize that NoSQL allows me to denormalize a lot of that data (which is
fine) in order to speed up processing/etc, and the concept of "tables" no
longer applies.    I'm fine with that.  But where I get lost is how to
organize similar datasets together in CouchDB.  In MongoDB, they have
Collections - akin to tables - to help separate data.

I don't see anything equivalent in CouchDB.  Which would mean to throw all
my data into a single "bag"/collection and rely entirely on map
functions/views to help organize data.  For instance, to retrieve all users
from the system, I would need a map function that does something like:
 emit all docs that have a username field.

But then what happens if at a later point in time, I create another
document that has a username field (which isn't a user)?  It will break my

So then my second option becomes to assign a "document-type" key to every
document and then filter upon that.  Where my "document-type" key is akin
to an organizational/collection name.  It's definitely better, but still
seems a little odd.

The whole process seems very disorganized.

I understand the concept that NoSQL is exactly that - a key/value store,
where structure is omitted. But I would have expected at the very least
some organization ability - no?

Am I missing something basic/obvious in CouchDB?  Or is the concept to use
separate DBs everytime you want to organize similar data together?  That
also seems a little odd too.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message