In the first video I watched over the weekend, Damien Katz, the creator of CouchDB, gives some advices as about when one should use the document database, which CouchDB is. He suggests to look at the real world task that is being computerized. If one would use a number of pieces of paper that are passed around to different people than is a every good indication that document based database will suit the solution well. In addition, if the piece of information is to be taken offline to be edited and later on replicated to the server to reflect the most recent version of the document, CouchDB is something to consider. Katz said that with CouchDB he is trying to bring the Lotus Notes model of document centered database to the open source world. He touches a bit upon Google’s BigTable: he believes that it’s only benefit is scalability and that CouchDB is trying to address different problems. CouchDB allows to create a view of the data whereas BigTable if just “this big key value table store.”
By the way, I also learned that Exchange was suppose to be an MS version of IBM Lotus Notes document database but it did not work out quite that well.
In the 2nd video, the presentation given by Katz at RubyFringe, I did not expect to find the great presentation about doing what you like and enjoying life (reaally something I did not expect). The stuff was good but not much practical info about CouchDB.
While browsing through planet@CouchDB I have found an excellent post about how CouchDB can make all ORM/GORM stuff obsolete. Since CounchDB does not enforce particular schema, my understanding is that all the document that are stored can be quite different i.e. contain different set of attributes. That really makes sense but I am still not sure if this is good – for sure it makes things easier in the beginning. The question that bothers me is how that affects the system once its running. What if we store a number of documents with one set of attributes and then update the view/editor to include some more. Data will be inconsistent and may lead to unpredicted results. It requires some additional checking for the presence/notnull/whatever parameters when working on the view part. If we were to use traditional/relational/schema model It would be required to alter the schema before new version could be up and running. It would be an explicit step to make sure that all the old data is suitable for new view.
Resources
Measuring performance
