I did some reasearch into OODBMS last year and found they have severe performance issues. Cache' was one I looked at. They also have not lived up to their hype for removing the Object/Relational Impedence Mismatch. Check out http://blogs.tedneward.com/Default.aspx#a33e0e84c-1a82-4362-bb15-eb18a1a1d91f and Ted's followup at http://blogs.tedneward.com/Default.aspx#a41c78696-d6ce-4381-bbf7-488bbd9bc6ef where he states (emphasis my own), "OK, but where can I go to get more info about these other languages/approaches?" Keep your eye on LINQ, for starters, as that's one of the first mainstream attempts to bring some of these ideas into traditional statically-typed object platforms. Scala and F# I already mentioned. Ruby is another place to spend some time, as there's a lot of features Ruby has that are trying to make their way into other languages. And, although I will likely gather some serious heat for saying this, Visual FoxPro may have some of the most interesting "best of both worlds" mojo in the entire language space on this subject."


>Our group has made decision to abandon relational database design and start using "post-relational" DBMS Cache' from InterSystems.
>
>The reasons for this decision was:
>1) Understanding of "impedance-mistmatch" problem between object model and data model. Simply we still need an ability to save our objects to database and ability to query this object data. We don't want to define each entity in terms of class and table and then establish object-relational mapping layer.
>
>2) Understanding that we are dealing with granular multidimensional data and our actions to fit it within tables lead us to loosing some data, storing of duplicate or sparce data and to growing query comlexity or even to usage of EAV concept which cannot be queried by standard means.
>
>3) Understanding our need for dynamic scheme evolution. We need configurational data to define data scheme for application data.
>
>All this problems lay out of relational concept. Even while some RDBMS vendors had solved some of them switching from VFP to any other relational system doesn't solve them all. Even more most of these problems could be theretically solved within VFP (and we produced partial solutions in any our project). But why we need to do this hard additional work if there are systems which does not have such problems?
>
>The key features we found in Cache' was answers to our very old questions:
>1) Unified data architecture allows to define an entity only once and only as a class. This is not another OODBMS or ORDBMS. (First was sick with queries and second still have object-relational mapping.)
>With Cache' the same data "projected" as objects and table rows for SQL access. For example, if class A inherits from class B we don't need to establish 1-1 relation. We see two projected tables A and B, where table B contains both inherited and new properties while inherited properties automatically have same values as in A table for same entities. This is almost impossible with traditional RDBMS.
>
>2) We can define embedded object properties and even arrays of embedded objects to store multidimensional data of complex structure while these data is still projected for SQL access. We can define many to many relations without dealing with correspondence table. In most cases we can use queries without slow multiple JOINs. The data is actually stored not in tables but in multidimensional sparse arrays preserving our logical tree-like structure and allowing faster retrival and queries on specific data.
>
>3) Witch Cache' classes and tables (as they are same in unified architecture) can be edited either manually or automatically via code or using SQL DDL. Defining class via code is not another code generation. In Cache' we work with class definition object representing properties as collection of property definition object. Now we can easily merge stored configurational data about attributes with our dynamic data scheme.
>
>I don't say traditional DBMS are bad. I don't say procedural programming is bad. OOP inherits procedural programming concept but allows to deal with high code complexity more easily.
>And I believe post-relational databases will be the same for DB world as objects for programming world.
>I don't advertise Cache', I believe there will be more other "postrelational" DBMS from other vendors.
>
>Hope this information will help somebody facing same problems.