Re: Saving OO objects in a relational database.

Paul Reed's book "Developing Applications With Visual Basic and UML" has a section of alternatives for mapping OO data structures into a relational database, including a comparison of performance implications of each one. Whether that book's alternatives are sufficient to meet your needs is another question (It certainly doesn't address your issue of storing multiple-dimension arrays.) In a nutshell, the alternatives he covers are:

1. store everything in one table
2. create one table per class and one SQL view per superclass/subclass relationship
3. create one table per subclass (or I expect in the case of multiple levels of inheritance, per "leaf" class) that includes superclass attributes as well

Bob Rosen

Raimundo Lozano <rlozano_at_medicina.ub.es> wrote in message news:39479869.2F6A09A4_at_medicina.ub.es...
> Try
> http://www.AmbySoft.com/mappingObjects.pdf
>
> Gooli wrote:
>
> > I am working on a project that requires the storage and loading of
> > complex C++ objects in a relational (Oracle 8.0) database.
> >
> > The C++ structure has many level of inheritance, and what is more
> > intimidating, is the fact that the objects to be saved contain multiple
> > dimention arrays.
> >
> > I am looking for information on the Internet, that descrtibes solutions
> > for problems of this kind (storing and loading complex OO structures
> > in a relational database). Names of books, and references to companies
> > that can offer consultation on the subject are welcome as well.
> > The main issue here is speed in both fetching the information and
 storing
> > it in the database.
> > Until now, due to the complexity of the data we were saving the objects
> > as LONG RAW (using MFC's Serialize) but this way has many limitations,
> > and defies the purpose of a relational database.
> >
> > Any comments will be greatly appriciated, as well as requests to post
> > the details of the design.
> >
> > P.S.
> > We use ADO for the communication with the database, so nested tables
> > and object relational design are not relevant (unless they added things
 to
> > ADO that I don't know about)...
>
Received on Wed Jun 14 2000 - 00:00:00 CEST