Re: Object oriented database

On Nov 1, 9:42 am, patrick..._at_yahoo.com wrote:
> On Nov 1, 9:20 am, "Walter Mitty" <wami..._at_verizon.net> wrote:
>
>
>
> > <patrick..._at_yahoo.com> wrote in message
>
> >news:d7f36b69-c7ae-4e65-b4ce-fdbc3345bd33_at_u18g2000pro.googlegroups.com...
>
> > > 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.
>
> The biggest weakpoint with dbms is that it was pretty darn hard to
> modify either the tables or the relationships (sets). Pretty much was
> a process of 'unload/reload', but the fact that organizations were
> running routinely on '386 class hardware' does not escape me. I
> remember at least one project keeping the transactional database on
> dbms and farming out the reporting to an oracle server with nightly
> datamart dumps.
>
> Digital's datatrieve and cdd was very forwardlooking at the time
> (imo), and I would see secretaries using 'ade' or something in telnet
> windows to create entire applications and building their own queries
> without the it deparment knowing anything about it. Obviously the cdd
> could target rdb and regular files too. I remember the entire product
> line from digital's database folks to be incredibly interesting.

Also, dbms did have schemas. I'm thinking that schemas could be a service also. On dbms on vms, you could essentially use cdd as sort of your schema repository. The interesting thing about cdd is that its permissions really looked and acted like file system permissions with simple inquisitive end users like me able to build table definitions. Obviously there wasn't much standard about this, very proprietory, but digital as a software company seemed very competent, if less than competitive in the market. Rdb was a very respected piece of work for instance. Received on Sat Nov 01 2008 - 16:07:08 CET