>> 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 up. Chris -- Chris Anderson http://jchris.mfdz.com
