Object Programming’s “is-a” and “has-a” strait-jackets

I had a brief encounter with a member of a 1990's 'object database' team some weeks ago, and when he asked why I thought the so-called OODBMSes had failed, it provoked a lot of thought. When it comes down to it, I have to think it is because the object model is built around two kinds of data relationships: "is-a" and "has-a." That is - object class hierarchies, and containment hierarchies. I'm sympathetic to the object-oriented mindset, really I am. There is a ton of power to be gotten from inheritance hierarchies. But taking this powerful abstraction and making it the principal relationship among data is simply a refusal to truly understand one's data on its own merit. And "has-a" is really not much better. The relational model and see that it says there are different kinds of relationships but it doesn't assume any are superior or preferred. You cannot say every data relationship is "is-a" or "has-a." The relational model allows the designer to specify any relationship desired and attach to it any attributes that are needed or are intrinsic to the problem being modeled. Where does the object approach stop scaling?  When it hits the need for data object reuse - identity.  Identity is extremely weak in object systems, but when you build it in, you find yourself building unique keys and indexes. When you start providing different presentations of the same data in an object system, you start building a query system. If you build a successful application - commercial, hosted, or internal - you will face a need for these capabilities within a year or so, maybe earlier.  At that point, if you have used an object, you are likely to be unhappy that you have limited yourself to inheritance and composition.  You'll start building identity and query mechanisms - you'l start building a relational database. You want objects - but you need a relational database.