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.
https://cloudant.com/handling-relational-data-with-cloudant-webinar-playback/
--
Andy Dorman
Ironic Design, Inc.
AnteSpam.com, ComeHome.net
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.
