Sitting on the couch
CouchDB is one of the most famous open source document-oriented databases available on the web.
This article described my experience with CouchDB during an university project, after having worked only with relational databases for years. I never had time to try NoSQL at work, since we are strictly coupled on the relational database and to an ORM on top of that.
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.
What is different in CouchDB
No schema, obviously
I found difficult to create fixture data manually without a reference schema, an automated script would probably be better. The flexibility of CouchDB is of course, that you don't have to follow a schema like an SQL table definition, and can add fields/columns to single documents at will.
Easy Linux installation
Like you would with a LAMP stack, with a single command you can get a running CouchDB instance on your Linux box. For example, ob Ubuntu
sudo apt-get install couchdb
will get you a running server on port 5984. Ubuntu already uses CouchDB in production to synchronize Ubuntu One stuff.
Keys are not sequential anymore, but UUID or manually specified.
These identifiers are thought for easy distribution of data across multiple noes, but I have not explored that in this primer. A sequence of natural numbers for IDs is only handy in a single-node database.
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...
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.
CouchDB talks HTTP
Views are loosely the CouchDB equivalent of SQL queries. However, you don't write them with a declarative language like SQL, but with a couple of map/reduce functions that follows in fact the Map/Reduce paradigm.
Now why whould you want to do that low-level work? First, you'll have a lot more flexibility in filtering data, and in building the data structure you choose to return. The flexibility - which can be dangerous in the wrong hands - is thus reflected both at the schema and the query level.
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. When a field change, the number of operations performed to update the views on N documents is O(log N), since the modified document is the only one to be mapped again, while the other intermediate (and unchanged) results are already stored.
This lower level of abstraction is beneficial to performance, but it implies however that you have to think about queries before starting to populate your database, because some queries may be impossible or perform very poorly with a particular data model. The latter is often true also for SQL-based queries however.
With CouchApp instead you can generate the structure of your folders, writing functions each in its own .js file with syntax checking, and then push your app to a live CouchDB instance.
I coded with the aid of a local git repository and then pushed my examples to the localhost server with couchapp push $databaseName (the term push is coincidentally the same as for Git, but it means deploy in CouchApp.) I'll definitely advise you to use CouchApp if you want to try out CouchDB without other hassles.
I like how CouchDB, and the NoSQL movement in general, change assumptions about what we need from a database. We have heavy, strictly consistent relational databases, as well as simple, fast and eventually consistent ones like CouchDB. Finding a match for our use cases is now simpler, more than it would ever do with a thousand other open source relational databases.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)