The author points at the three reasons for OODBMSs not catching on being

1. DBAs don't understand them (i.e. can't optimize them by adding an index, can't maximize storage space with partitions, etc.)
2. Developers don't understand them
3. Not backed by a powerhouse (i.e. Microsoft, Oracle, or IBM)

Actually the only reason of any merit I can see is (3). Many DBAs and developers don't really understand the finer points of relational theory yet this doesn't prevent them from banging out SQL. Perhaps On the opposite end is XML which from what I've seen most people don't understand the fundamentals (the amount of people who don't even get XML namespaces is mind boggling) yet has ended up in the three major RDBMS products. This seems to indicate that major vendor support is what matters and the rest falls into place. Or so it seems...

When I wrote An Exploration of Object Oriented Database Management Systems which eventually ended up on Slashdot and K5 there were three major technical points against OODBMSs which are hard to argue against

• Schema Changes: In an RDBMS modifying the database schema either by creating, updating or deleting tables is typically independent of the actual application. In an OODBMS based application modifying the schema by creating, updating or modifying a persistent class typically means that changes have to be made to the other classes in the application that interact with instances of that class. This typically means that all schema changes in an OODBMS will involve a system wide recompile. Also updating all the instance objects within the database can take an extended period of time depending on the size of the database.
  
  
• Language Dependence: An OODBMS is typically tied to a specific language via a specific API. This means that data in an OODBMS is typically only accessible from a specific language using a specific API, which is typically not the case with an RDBMS.
  
  
• Lack of Ad-Hoc Queries: In an RDBMS, the relational nature of the data allows one to construct ad-hoc queries where new tables are created from joining existing tables then querying them. Since it is currently not possible to duplicate the semantics of joining two tables by "joining" two classes then there is a loss of flexibility with an OODBMS. Thus the queries that can be performed on the data in an OODBMS is highly dependent on the design of the system.
  
  

The above three are all significant disdavantages taken singly [especially the third] but together it is clear that whatever benefits OODBMSs provided over RDBMSs that they came at too high a cost. Moving from an RDBMS to a system where database changes are tightly coupled to the application code, applications are tied to a single language and queries are inflexibly bound to application data structures is a step back for most RDBMS users. It should be noted that although OQL provides mechanisms for performing joins and constructing new structs from intermediate query results, these features were rarely supported in commercial OODBMS products and even then do not provide the rich ad-hoc query facility of the SQL language.

The final nail in the coffin for OODBMSs was the rise of the Object Relational Database which supposedly combined the ability to store complex structures inherent in OO DBs with the rich query features of Relational DBs system. I'm not sure about my employer or IBM but I do know of the existence of Oracle Objects. Funnily enough, it seems that most customers aren't even interested in this functionality in Oracle's products given comments by Mark Scardina at XML 2002. So it looks like even with major vendor support, customers weren't as interested in OO DB features as was speculated when Object Oriented Databases were all the rage.

I currently see the same situation repeating itself with native XML databases. Comments by various employees of relational databasevendors and native XML DBvendors jibe with some of the thoughts I had when I wrote An Exploration of XML in Database Management Systems . The general consensus from various sessions at XML 2002 is that relational DBs have or will adapt to support all the best parts of the functionality supported by native XML databases with the added bonus of throwing in 30 years of relational database experience and functionality as well to boot. Even the native XML DB vendors seemed to admit this add were pitching their products as niche products instead of replacements of RDBMSs which is wise given how this pitch backfired on the OODBMSs before them.