Object oriented database

mrtomas.DeleteThis@tpg.com.au wrote:

> Hi all,
>
> I am looking for people who have an interest in object oriented
> databases, primarily to share ideas or to find out end-user
> requirements.

Plus ça change... ::sigh::

Good luck with that
 >> Stay informed about: Object oriented database 

On Oct 30, 11:36 pm, mrto....RemoveThis@tpg.com.au wrote:
> Hi all,
>
> I am looking for people who have an interest in object oriented
> databases, primarily to share ideas or to find out end-user
> requirements.
>
> I am currently working on an object oriented database product, which
> will be closely tied in with the programming language of choice. First
> goal is to make a C++ implementation, and later Java, C# and web
> scripts like PHP.
>
> Anyone with interest into the subject, please send me an email. You
> can see some of my products and the ideas for the OODB on my web
> site:http://www.clear-objects.com
>
> Best regards
> Tomas


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.
 >> Stay informed about: Object oriented database 

On Oct 31, 3:41 pm, wrote:
> On Oct 30, 11:36 pm, mrto....TakeThisOut@tpg.com.au wrote:
>
>
>
> > Hi all,
>
> > I am looking for people who have an interest in object oriented
> > databases, primarily to share ideas or to find out end-user
> > requirements.
>
> > I am currently working on an object oriented database product, which
> > will be closely tied in with the programming language of choice. First
> > goal is to make a C++ implementation, and later Java, C# and web
> > scripts like PHP.
>
> > Anyone with interest into the subject, please send me an email. You
> > can see some of my products and the ideas for the OODB on my web
> > site:http://www.clear-objects.com
>
> > Best regards
> > Tomas
>
> 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.

I hope never to use one of your systems. You don't even know what you
are talking about. I do not mean to be offensive, just trying to wake
you up if it can be done. Please read and choose what you read
carefully.
 >> Stay informed about: Object oriented database 

wrote:

> On Oct 30, 11:36 pm, mrto... DeleteThis @tpg.com.au wrote:
>
>>Hi all,
>>
>>I am looking for people who have an interest in object oriented
>>databases, primarily to share ideas or to find out end-user
>>requirements.
>>
>>I am currently working on an object oriented database product, which
>>will be closely tied in with the programming language of choice. First
>>goal is to make a C++ implementation, and later Java, C# and web
>>scripts like PHP.
>>
>>Anyone with interest into the subject, please send me an email. You
>>can see some of my products and the ideas for the OODB on my web
>>site:http://www.clear-objects.com
>>
>>Best regards
>>Tomas
>
> 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.

Sorry, but plonk.
 >> Stay informed about: Object oriented database 

On Oct 31, 6:20 pm, Eric wrote:
> On Oct 31, 3:41 pm, wrote:
>
>
>
> > On Oct 30, 11:36 pm, mrto... RemoveThis @tpg.com.au wrote:
>
> > > Hi all,
>
> > > I am looking for people who have an interest in object oriented
> > > databases, primarily to share ideas or to find out end-user
> > > requirements.
>
> > > I am currently working on an object oriented database product, which
> > > will be closely tied in with the programming language of choice. First
> > > goal is to make a C++ implementation, and later Java, C# and web
> > > scripts like PHP.
>
> > > Anyone with interest into the subject, please send me an email. You
> > > can see some of my products and the ideas for the OODB on my web
> > > site:http://www.clear-objects.com
>
> > > Best regards
> > > Tomas
>
> > 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.
>
> I hope never to use one of your systems. You don't even know what you
> are talking about. I do not mean to be offensive, just trying to wake
> you up if it can be done. Please read and choose what you read
> carefully.

lol I surrender! plonk me already!
 >> Stay informed about: Object oriented database 

On Oct 31, 7:41 pm, wrote:
> On Oct 30, 11:36 pm, mrto... DeleteThis @tpg.com.au wrote:
>
>
>
> > Hi all,
>
> > I am looking for people who have an interest in object oriented
> > databases, primarily to share ideas or to find out end-user
> > requirements.
>
> > I am currently working on an object oriented database product, which
> > will be closely tied in with the programming language of choice. First
> > goal is to make a C++ implementation, and later Java, C# and web
> > scripts like PHP.
>
> > Anyone with interest into the subject, please send me an email. You
> > can see some of my products and the ideas for the OODB on my web
> > site:http://www.clear-objects.com
>
> > Best regards
> > Tomas
>
> 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.

AFAICT this poster is exhibiting symptoms of trolling (I refer you to
the rash of posts across threads).Trolls intend only to generate
negative reaction and bring attention to themselves. There is no
reasoning with them, and the only way to deal with them is to not
react at all.

I implore you not to feed this one (even when it replies to this
post). Regards, J.
 >> Stay informed about: Object oriented database 

On Nov 1, 7:39 am, JOG wrote:
> On Oct 31, 7:41 pm, wrote:
>
>
>
> > On Oct 30, 11:36 pm, mrto....TakeThisOut@tpg.com.au wrote:
>
> > > Hi all,
>
> > > I am looking for people who have an interest in object oriented
> > > databases, primarily to share ideas or to find out end-user
> > > requirements.
>
> > > I am currently working on an object oriented database product, which
> > > will be closely tied in with the programming language of choice. First
> > > goal is to make a C++ implementation, and later Java, C# and web
> > > scripts like PHP.
>
> > > Anyone with interest into the subject, please send me an email. You
> > > can see some of my products and the ideas for the OODB on my web
> > > site:http://www.clear-objects.com
>
> > > Best regards
> > > Tomas
>
> > 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.
>
> AFAICT this poster is exhibiting symptoms of trolling (I refer you to
> the rash of posts across threads).Trolls intend only to generate
> negative reaction and bring attention to themselves. There is no
> reasoning with them, and the only way to deal with them is to not
> react at all.
>
> I implore you not to feed this one (even when it replies to this
> post). Regards, J.

Really, this is like the 2nd or 3rd post hinting that I'm a troll. Its
off topic and borders on irritating spam. If you want an relational
specific theoretical group, just say so and I'll propose it myself in
the proper newsgroups. I wouldn't be surprised if I'm not the only one
who has ever wished you idiots would just shut up. Theres plenty of
polite rdbms experts that would probably still be able to visit here
without my morning coffee posts sending them into downward spirals of
angst and paranoia.
 >> Stay informed about: Object oriented database 

On Nov 1, 9:20 am, "Walter Mitty" wrote:
> 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.

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.
 >> Stay informed about: Object oriented database 

On Nov 1, 9:42 am, wrote:
> On Nov 1, 9:20 am, "Walter Mitty" wrote:
>
>
>
> > 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.
>
> 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.
 >> Stay informed about: Object oriented database 

On Nov 1, 10:12 am, "Walter Mitty" wrote:
> wrote in message
>
>
>
> > 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.
>
> By 'dbms' do you mean VAX DBMS?
>
> > 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.
>
> Datatrieve was very interesting form the point of view of "integrating
> relational and non relational data", something I said in another reply.
> By using Datatrieve's CROSS operator, you could, in effect, join data from
> a relational database like VAX RDB with data from a non relational database
> like VAX DBMS, or from RMS files. If you could get through a gateway you
> could even use data from IMS, IDMS, or CICS.
>
> In particular, the CROSS operator had no particular difficulty in dealing
> with repeating groups. It made input from files with repeating groups "look
> flat".
>
> So, would an up to date datatrieve do what you want? Why or why not?

No, in this thread its still the persistance. Sticking with dbms to
keep it familiar, it had features when defining your records and
relationships in such a way that these 'sets' already knew what
records would be returned in a join. The ultimate precalculation is an
actual list of disk offsets that you can then go fetch your
subordinate records in the relationship (between parent and children
hierarchialwise, or records on each side of the join. This needs an
interface that either does not need a 'join', or otherwise lets my
join actually specify the children (members) in the set. In some cases
the disk offsets are really into the very record you have just fetched
(repeating groups), but the fact that there are children records
subordinate to a parent rec is easily visualized. Its what pick folks
call a 'nested relation' I think

Yes, rdbms has this where the actual implementation of the database is
not specified, but no, today's rdbms often will not let me specify it
either in the language or an out of band 'hint' that I'd like the
subordinate records to maybe actually be a repeating group. The
products that do allow repeating groups are seen as wimping out on
rdbms dogma.

The very small engine I worked on for a bit ditched the schema
entirely. For each key in a record that points to another foreign key
containing record, there are actually two or more storage locations,
one for the application generated key, and one for the cached
resolution of where the record actually is. Space time tradeoff of
sorts. I literally do not even want to calc a hash. Records can also
be marked as 'prefer to be cached and writethrough.'

Yes I know rdbms theory probably doesn't want to hear about that sort
of stuff. Thats what killfiles are for.
 >> Stay informed about: Object oriented database 

On Nov 1, 11:39 am, Bob Badour wrote:
> Walter Mitty wrote:
> > There is, of course overhead associated with schemas, etc.
>
> How exactly does the overhead associated with a schema differ from the
> overhead associated with a namespace?

I guess it would be in my case it would be in addition to the
namespace but I guess lugging around an sql interpreter would
ultimately not make much of a difference so thats a good point.
 >> Stay informed about: Object oriented database 

"Eric" wrote in message

On Oct 31, 12:36 am, mrto... DeleteThis @tpg.com.au wrote:

> I am looking for people who have an interest in object oriented
> databases, primarily to share ideas or to find out end-user

>That would be an exiting topic if there was an OO data model.

I apologize for calling attention to a typo. I make lots of typos myself.
But "really exiting topic" for "really exciting topic" (I guess) is a
classic! It's a keeper!
 >> Stay informed about: Object oriented database 

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.
 >> Stay informed about: Object oriented database