Re: Object oriented database

From: Walter Mitty <>
Date: Sat, 01 Nov 2008 14:20:40 GMT
Message-ID: <YAZOk.1955$>

<> wrote in message

> I think an interesting project would be to implement transactions
> without all the relational stuff. I bet there would be quite the
> interest in having solid persistance services without having to carry
> around schemas, triggers, sql, relational algebra, etc, sort of what
> todays transactional file systems do for metadata, make available for
> object persistance.

It's been done, dozens of times, back in the 1970s. One such implementation was VAX DBMS. This was a network (CODASYL) database, with full support for transaction control. While there is no explicit OO model of data, it is reasonable to speak of an implicit OO model of data anyway. Because it's implicit, it's dificult to say exactly what its features are, because it can differ idiosyncratically between one developer and the next.

The OO data model, such as it is, differs only trivially from the network data model. And the network data model differs only mildly from the hierarachical data model. Like the OO data model, neither the network nor the hierarchical data model were explicitly developed as such. Instead, they were retroactively developed from DBMS implementations for the sake of comparing the data models to the relational data model.

Some people who thought fairly deeply about this matter concluded in the 1970s that the relational model was superior in several fundamental ways to the network and hierarchical data models. There is, of course overhead associated with schemas, etc. and the desire to get rid of that overhead is a legitimate desire. An interesting question is whether the resulting class of products should be called "database management systems" or "application persistent store management systems" or something like that.

It would behoove you, before you invest too much effort in recreating what was done in the 1970s, to see what it is that they did, and what the strong and weak points of their approach was. You might be able to save yourself a lot of time and effort that way. Received on Sat Nov 01 2008 - 15:20:40 CET

Original text of this message