This is a very interesting quest and I hope you check in from time to time with your findings. For what it's worth, object-oriented DBMSs are not a new concept. I first heard about them at a database development conference in 1989. I don't know why they haven't caught on more. Maybe Craig is right that performance is the issue.


>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.