It is new, I'll give you that. I'm not sure who you mean by "these people". CouchDB is a document database not a relational database. Comparisons are made mostly to help folks understand the differences not to argue superiority. One argument is that a schema-less approach solves the issue of dealing with schema evolution. Having worked with O-R mapping issues for years as well as OODBs and persistent heaps and so forth I think document databases provide a fresh look. The technology choices of JSON over HTTP, Javascript and Erlang all the way down are also very compelling. It strikes me as just good timing. YMMV
> One argument is that a schema-less approach solves the issue of dealing with schema evolution.
That part's not new. I worked in a Notes shop back in the 1990s, and the inevitable result of this was that every database was littered with documents created and updated by so many different versions of the apps that not even the developers really knew whether any fields could be relied on and which features would work for a given document without unpredictable failures.
That's a discipline issue. Nothing stops people from writing their apps to do data migration on update. That is, have their model classes fill in any missing attributes with default values etc. before saving it back. The difference is that you can do it selectively.
Nothing stops people from creating retarded schemas for RDBMS's either.
Data migration requires a list of what the data looks like as of each version. Doing that by hand is just as much work as maintaining a schema, with the disadvantage that you'll find out the hard way, too late, whether it reflects reality.
