This article described my experience with CouchDB during an university project, after having worked only with relational databases for years. […] This experience has been a spike: it is not test-driven, and will be thrown away once the project is finished. It is incremental, tough, since this is an effective way to learn a new technology.
I don’t agree with everything written in there, but I’m wondering how many have reached similar conclusions.
A couple of suggested corrections:
Eventual consistency: Your views will be consistent with your state sometime (at an unstated time point in the future). This is definitely dangerous for most of enterprise databases, but if you’re managing a social network timeline, however…
Views are updated by default on your first query to them. That basically means that the results you’ll be getting are consistent. CouchDB is offering a way to “relax” this behavior by using a
stale=ok parameter in which case the view will return the existing results without trying to update the view with latest data.
Values are not atomic: While in a relational table’s row a value for a column defines a strict type, you can store what you want as a property of a document. For example, arrays or other objects. In fact, CouchDB thinks of a document as a JSON value, as it is built for the web.
I think that a better way to call this is schema-less or not-enforced schema or document based models. Usually atomicity is referring to transactions: “database modifications must follow an ‘all or nothing’ rule”.
MapReduce: More importantly, map-reduce is how far you can get with a general paradigm for querying which still is intrinsically parallelizable. Map functions can be executed on different nodes, and reducers can be placed on different nodes too.
While theoretically true, one should know that CouchDB is not parallelizing either
reduce phases. Though BigCouch, the scale out CouchDB solution will work this way.
Original title and link: Notes on CouchDB: Sitting on the couch (NoSQL databases © myNoSQL)