business evolves. This is why often the focus is on process rather than objects. In reality there are no real classes of things, just instances, each distinct.

business evolves. This is why often the focus is on process rather than objects. In reality there are no real classes of things, just instances, each distinct. The key word you mention is "structured". Sure, if you're building apps to support the DMV where documents and forms change once every 30 years and people work for life sitting there doing data entry on screens that look like those forms then it's a safe bet you can design a relational schema that supports this. The same holds for banking and other transactional settings. The relational approach is powerful, with an algebra to back it up and support a query language. So where do you put the logic, business rules, integrity constraints that govern this data? In stored procedures, key constraints? Or does it leak into the application code, especially if the code is OO. Using OOP how do the objects map to the tables? Some high level abstraction like hibernate that presumes to make that declarative and automatic? Now what if the schema is not so static, suppose it's dynamic. How does it evolve? I think what many have recognized is that there is considerable overlap in the db world with app servers and web servers. The web is a much more dynamic place and increasingly I think relational databases are used more for just simple storage. We've all used RDBMS for years and they've had loads of PhD theses put into making them what they are. Sometimes a different view is helpful. CouchDB has a dirt simple REST based API. It uses JSON for communication and Javascript in the database. It lets you store almost anything you want and it supports replication. For a real world scenario think of say something like a web-based lotus notes that supports on and off line use and collaboration. Another very interesting aspect of CouchDB is it's choice of implementation language, Erlang. What it inherits from OTP is readily seen in the small amount of code needed to implement it. Moreover when it comes to robustness Erlang is frightening in how rock solid it is. For what it's worth I think it's a keeper