incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Johnson <>
Subject Re: new couch user: "denormalizing" using views? General application architecture suggestions?
Date Mon, 07 Feb 2011 23:30:35 GMT

Couch is very different from a RDBMS. From what you have said, I think that you want to load
your CouchDB "one document at a time" as users access them in a browser session. 

Before loading anything you first need to design your documents. To do this you need to define
the data in your database tables as "documents" as opposed to related tables. For example,
a sales invoice in RDBMS terms would have order header table and order details table with
a one to many relationship between them. In Couch you would have a single document for each
order which would have all the order header data in it and then multiple order lines all in
the same document. If you were to express it as a PHP stdObject you would have something like


Couch will let you store the above object as a document and retrieve it via keys.

To retrieve the documents via keys, you would build couch views with the relevant key/value
pairs (e.g. order_ref)

Once you have done the design you can load document by document by altering your application
to assemble a document from your RDBMS when a user asks to see it and saving the document
to couch. One intricacy would be to know which documents were saved in couch and which not.
You could either alter your existing app to store the couch document id in the RDBMS which
you could check for or you could try and retrieve from Couch first and if you fail to find
it you could go to your RDBMS

Hope this helps


On 7 Feb 2011, at 17:14, Michael Kohout wrote:

> Hi All-
> So, I'm doing a spike on what it would take to convert a portion of an
> existing rdbms-backed system to something that uses couch instead.  I'm also
> pretty green with couch.
> Because this would be a conversion from a relational system, the way I
> envision the system working is that it will take row-like documents as
> input, then, at some point inside couchDB these things will be denormalized
> into documents to be reduced.
> The way I see it, there is one, possibly two ways to do this:
> 1)  through the _changes feed.  This seems like it's the most couchy way to
> do things.  However, for this application it also seems like it's the most
> complex way to implement-the current system has a pretty large number of
> normalized, interdependent tables and I'd like to not force a specific order
> for things to be loaded into couch(I don't want to force the system to work
> via a batch load-ideally, it'll be driven by user input via a browser).  So,
> I'd essentially have to handle all places where a "row" is used when
> denormalizing via _changes.
> 2)  via a view(IF there is a way to mark other documents as part of a view).
> It looks like, at least if I use an external view server, I could build the
> denormalized docs during the map which'll be processed during the reduce.
> This would be super simple(in my opinion) for implementation, but it
> doesn't seem like couch offers functionality for generating multi-document
> views(while also hooking into couch's view-invalidation mechanism, so that
> if one of the docs that make up this view is changed, the view will be
> regenerated).  Am I wrong?  Is this something that is planned?
> What does the couch community think of this?  Is there some other pattern
> that might result in a simpler system?
> Thanks for any suggestions you might have, and if I haven't been clear about
> what I want to do, please feel free to ping me on it.
> Mike Kohout

View raw message