couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <>
Subject Re: When to use CouchDB, when not to...
Date Tue, 14 Oct 2008 03:06:56 GMT
>> The sort of architecture I've been contemplating is one where certain
>> heavyweight entities in the application would be stored in CouchDB while
>> other lighter weight/more relational entities would remain in the RDBMS.

I like draw a distinction between documents that can be edited, and
documents that are write-once. The second type is great for
logging-style data collections (which lend themselves to MapReduce
reports), while the first fits most handily with data collections that
will be edited by the user.

Unless you have data that really hits the RDBMS sweet-spot (social
graph, maybe...) I'd make a go of designing a system that uses only
CouchDB for persistence. I'm leaning this way, because I think there's
a lot of space to be explored in terms of how to structure and
maintain document based applications.

I guess I think the overhead of keeping the two systems in sync might
outweigh the benefits of "in the box" joins and such that you can get
from a SQL overlay. If you do go with a mixed system, it would be
interesting to hear how you handle any impedance mismatches that come


Chris Anderson

View raw message