couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Dorman <>
Subject Re: How to implement multiple-tables/collections using CouchDB?
Date Thu, 11 Sep 2014 20:07:42 GMT
On 09/11/2014 02:17 PM, Matthieu Rakotojaona wrote:
> Excerpts from Eric B's message of 2014-09-11 16:19:21 +0200:
>> 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
>> code.
>> 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.
>> Thanks,
>> Eric
> In CouchDB, the organization and planning you have to do is not in
> how you want your data stored, it's in how you're going to
> retrieve/query it. If you need to display the last 5 ordered items of a
> user a lot (as in, "here are your last 4 purchases"), you're going to
> write a view that allows you to do that easily. If you need to list all
> the orders that happened since beginning of the month, it will be the
> same. This is where the shift can be, coming from RDBMS.
> To be more precise, the map process happens somewhat like that (in pseudocode):
>      for doc in new_docs():
>        emit some_property from doc
> The key here is that CouchDB is targeted towards querying sorted things.
> You have to make it so that property sorts.
> For example, for the second example, you should emit the order date in a
> sortable date (use ISO8601). For the first example, on each order, emit
> something like "user_id:order_date" with a sortable order_date. When
> user_id 4 connects and fetches its 5 last ordered items, CouchDB will
> just iterate on the 5 relevant entries that you have indexed.
> "Indexed" here is the important word: "new_docs" evaluate to all docs
> when querying the view for the first time, but then it only evaluates to
> "docs that have changed/been added since the last time the view was
> queried". Results are incrementally stored for efficient querying.

I realize it is Cloudant, but would work as well for CouchDB...

I have been working with RDBMS since the late 70's and making the shift 
to a document db like CouchDB has been a bit of a challenge...but at 
least one light came on for me when I saw this webinar last week.

Andy Dorman
Ironic Design, Inc.,

CONFIDENTIALITY NOTICE: This message is for the named person's use only. 
It may contain confidential, proprietary or legally privileged 
information. No confidentiality or privilege is waived or lost by any 
erroneous transmission. If you receive this message in error, please 
immediately destroy it and notify the sender. You must not, directly or 
indirectly, use, disclose, distribute, or copy any part of this message 
if you are not the intended recipient.

View raw message