Debate: ODBMS sometimes a better alternative to O/R Mapping?

In a recently released article on ODBMS.org, Ted Neward elaborated upon his idea that Object/Relational Mapping (ORM) is the Vietnam of Computer Science. The main idea that he presents is that Object-oriented Database Management Systems (OODBMS) are better than Relational Database Management Systems (RDBMS) for some applications, for example:

"In situations such as "silo" applications where a single user interface accesses a single database (the traditional "baby webapp on top of a big database"), or the more leading-edge "service" implementations, however, all interaction will be through that user interface or service interface, and never against the database itself, thereby making persistence truly an implementation concern only. In these situations, an OODBMS back-end can be invaluable in defining and preserving a rich domain model, as now there are no entity definitions in two languages (Java/C# and SQL DDL) to be reconciled."

He also identifies the main issue that OODBMS tries to solve as the Dual-schema problem:

"[...] in a traditional object/relational world, two sets of entity definitions are in play: one defined by the programming language itself, the other by the relational model using SQL DDL. This sets up an inherent challenge, as now two sets of definitions must be kept up to date as the system grows and evolves, either by "slaving" one to the other (frequently seen by the use of code generation tactics, either from schema to classes or the other way around), or by editing/adjusting the two separately and hand-tuning the mapping between them as necessary. This creates a tension between the two, and frequently developers are forced to make sacrifices in the purity of both models in order to keep the two in sync with one another.

Again, in an OODBMS, the fact that the class definitions are the only schema present means that no such “dual schema” problem exists; the domain model need not be slaved to the storage definitions, and the storage definitions need not be twisted into strange formations just to support the storage of a rich domain model."

Some people agreed with this viewpoint, such as Andrew McVeigh:

"OO --> storing of complex graphs, fast navigation / traversal between objects, low impedance mismatch.

RDBMS --> data independence, suitable for complex reports, much better schema management (DDL).

Using an RDBMS for storage for a CAD system's diagrams, or an OODB for a reporting database is just asking for trouble."

However, there were also those who disagreed with this viewpoint, notably Gavin King, who wrote an article defending the role of the RDBMS. He brings up several points, a brief summary of them being:

• ORM is required for legacy data - ORM is the only way that you can handle existing schemas or support legacy data, so replacing it isn't an option.
• ORM can handle the DB for you - ORM solutions can generate the mappings and database schema for you if you don't have any backwards compatibility requirements.
• Data lasts longer than applications - Mapping is needed because data will almost always last longer than the application that created it.
• OODBMS is bad for compatibility - Because you store strongly-typed objects in the database, OODBMS is difficult to use with multiple development languages, whereas simple strings and numbers in an RDBMS can be mapped by each language.
• OODBMS is not mature enough - OODBMS isn't seen in major data management systems because it's very immature compared to most RDBMS systems
• Benchmarks showing OODBMS as being faster are flawed - OODBMS systems will normally run either in the same process as the app, or are written in an unscalable way - as a result, they do well in the small case, but are no good in the large case. As well, ORMs are slower because they are more robust - once OODBMSes incorporate a robust, mature featureset they will be the same speed

In particular, Gavin states:

"To be clear, using ORM technology introduces no new no "mapping" or "dual schema" problem unless one already exists, due to the requirement of access to legacy data. If you just want to "throw some objects in the database", you'll never need to write a single mapping annotation. So, from this point of view, ORM is at least as good as an object database for all usecases, and handles other usecases (indeed, the common cases) which the object database approach does not."

Gavin also said:

If you think that relational technology is for persisting the state of your application, you've missed the point. The value of the relational model is that it's democratic. Anyone's favorite programming language can understand sets of tuples of primitive values. Relational databases are an integration technology, not just a persistence technology. And integration is important. That's why we are stuck with them.

This resulted in a long follow-up by Ted Neward:

"since when does one tool solve all problems? They have their own raisons d'etre, and to simply say that the OODBMS or HODBMS should be ignored just because "we've always used an RDBMS" is a crime just as great."

Ted also disputes many of Gavin's points, including the following response to Gavin's assertion about the Dual-schema problem:

"Sorry, Gavin, but the fact is, this remains, and always will remain, a point of difference between you and I, and between you and a fairly large number of developers I've spoken to over the years at conferences and consulting engagements and classes. For simple table-to-class mappings, you're right, it's a pretty simple thing. It is, however, still a "dual schema" problem, in that now you have two competing "sources of truth" that have to be reconciled to one another, the database schema, and the object model. Now, perhaps if all the projects you've ever done are projects where the developer gets to define both, then the problem doesn't appear, but if you're in an "enterprise" world where the database schema is managed by a team of DBAs and is shared across projects, you don't have the flexibility to "refactor" the schema like you can your object model."

The debate appears to be only getting started - care to weigh in with your own opinion?