couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthieu Rakotojaona <matthieu.rakotoja...@gmail.com>
Subject Re: How to implement multiple-tables/collections using CouchDB?
Date Thu, 11 Sep 2014 19:17:07 GMT
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.

-- 
Matthieu Rakotojaona

Mime
View raw message