Re: Saving OO objects in a relational database.

You can also use ObjectDRIVER for your project

ObjectDRIVER is our new powerful ODMG-Compliant Open Object Wrapper dedicated to relational databases reusing. With ObjectDRIVER, a relational database can be full-accessible (selection, insertion, deletion, update) as an object database after that the object schema and its mapping on top of the relational database have been defined. The object data can be queried with OQL, the ODMG query language.

ObjectDRIVER (release 1.1.122) is now available for Borland C++Builder 5, Borland C++Builder 4 and Microsoft Visual C++ 6.0. Java Binding in all distributions.

The distribution can be obtained for evaluation from http://www.inria.fr/cermics/dbteam/ObjectDriver/.

Best regards,
Franck

"Gooli" <gooli_at_mailandnews.com> a écrit dans le message news: 8hqrb3$j63$1_at_news.netvision.net.il...
> 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 Fri Jun 09 2000 - 00:00:00 CEST