But most web data isn’t really relational. It is made relational to fit into a relational database, because that’s what we’re used to. Post + Comments? Post document + array of comments. Inline. Who needs relations here?

There are some great uses for couchdb, but I don’t think “a HTTP interface, fantastic scaling ability due to bi-directional replication, and schema free nature” are reason enough (in most cases) to try and map the functionality of a relational database onto document oriented database.

The 3rd approach though is still a pattern and something that could be added for associations (indeed I intend to do this). In the same way the more you use SQL you notice patterns and can abstract around them to make it quicker to use via an ORM, I believe the same happens with CouchDB. No abstraction can cover all cases though and that’s why you can define views manually (in the same way you can define SQL queries manually).

Personally I prefer to have the majority of cases handled for me and manage the exceptions myself although this does depend on the user having a knowledge of how CouchDB works.

you are talking about ORMs – that stands for “object relational mapper” and couchdb is not a relational database, i.e. there can’t be an ORM for couchdb. i know it’s just a small thing but i think getting the words right is important.

when you compare using activerecord as an abstraction on top of sql to using couchfoo as an abstraction to couchdb i think there is one important point you are missing: while activerecord allows you to generate some 99% of all the queries you will ever need this doesn’t work with couchfoo. you can only generate very basic and minimal map/reduce functions automatically and as soon as you start overusing that (by using couchdb like a relational database with loading relations and joining them) you very quickly start working against couchdb. i’m not talking about losing a bit of performance here and there (btw. i love how ativerecord abstracts away sql for me) but about missing the whole concept of how couchdb works.

to your document/comments example: suppose you want to show a list of documents with the number of comments on each. what you would do with activerecord is to load the documents first and then load all the comments to all the documents in order to count them (you would optimize this at some point and do a custom sql query that counts for you but that is something activerecord doesn’t help you with). now if you insist on doing this in couchdb the same way you are missing the fact that with more direct access to the couchdb API this would have been trivial and most efficient from the start without even thinking about optimizations. by keeping to the activerecord way you create yourself a class of problems you shouldn’t even have.