Re: Object oriented database
From: Walter Mitty <wamitty_at_verizon.net>
Date: Sat, 01 Nov 2008 21:04:54 GMT
Message-ID: <Wv3Pk.2023$225.1848_at_nwrddc02.gnilink.net>
>> <patrick..._at_yahoo.com> wrote in message
>>
>> news:ab77a4d8-c281-4417-af55-7f9b86af7fac_at_x1g2000prh.googlegroups.com...
>>
>> > 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?
Date: Sat, 01 Nov 2008 21:04:54 GMT
Message-ID: <Wv3Pk.2023$225.1848_at_nwrddc02.gnilink.net>
<patrick61z_at_yahoo.com> wrote in message news:30cd4b21-5cb5-4e23-8229-c9f2960967c7_at_u29g2000pro.googlegroups.com...
> On Nov 1, 10:12 am, "Walter Mitty" <wami..._at_verizon.net> wrote:
>> <patrick..._at_yahoo.com> wrote in message
>>
>> news:ab77a4d8-c281-4417-af55-7f9b86af7fac_at_x1g2000prh.googlegroups.com...
>>
>> > 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,
Familiar to whom? Received on Sat Nov 01 2008 - 22:04:54 CET