Newsgroups: comp.databases
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!geac!jtsv16!jtsv16!mark
From: mark@jtsv16.jts.com (Mark Booker )
Subject: Re: PICK dbms/os on UNIX
In-Reply-To: geckhard@ringer.cs.utsa.edu's message of 11 Jun 91 22: 44:03 GMT
Message-ID: <MARK.91Jun12123456@jtsv16.jtsv16.jts.com>
Sender: mark@jts.com (Mark Booker )
Organization: J.T.S Computer Systems LTD.
References: <10595@idunno.Princeton.EDU> <1991Jun10.223018.26414@ringer.cs.utsa.edu> <10628@idunno.Princeton.EDU> <1991Jun11.224403.9172@ringer.cs.utsa.edu>
Date: Wed, 12 Jun 1991 17:34:56 GMT

In article <1991Jun11.224403.9172@ringer.cs.utsa.edu> geckhard@ringer.cs.utsa.edu (Gary Eckhardt) writes:

   In article <10628@idunno.Princeton.EDU>
   gpmenos@phoenix.Princeton.EDU (G. Philippe Menos) writes: 
   >In article <1991Jun10.223018.26414@ringer.cs.utsa.edu
   >geckhard@ringer.cs.utsa.edu (Gary Eckhardt) writes: 
   >>PICK was a good idea at the time it was developed, leading the way for
   >>other database systems like itself, but it has grown sorta obsolete.
   >>
   >
   >Thanks for your views.  I wonder if you could elaborate on the term
   >"obsolete."  Could you give me some practical implications.  Later you

   An Example:  In PICK, you use the dictionary approach to data, specifying
   what that data looks like via formats, etc.  The only limitation was that
   a dictionary could not go beyond the boundaries of the data file, i.e. I
   could not include a dictionary item that was actually a data element from
   another data file.  To me, that was limiting, and obsolete, because with
   SQL you can develop Views that will let you do just that.

This is not quite true. The use of a 'correlative' data dictionary
item: "Allows am attribute value to translate through another file.
The attribute referenced in line 2 of the dictionary definition item
is assumed to be an item-id in the specified filename." 

This feature allows you to, say -- store a customer-id in a invoice
master file and using a 'correlative' dict item look-up the customer
master record by item-id and retrieve any field with-in that file, say
customer name.

   >>Working with a 9-Track tape drive on the Honeywell system, it
   >>took more than 72 hours to complete a file restore.  Working with
   >>a 9-Track tape and the PC version of PICK, it took closer to 5 days.
   >
   >This does sound excessive, to say the least.  But could you tell me the
   >approximate size of the database in question, so I have a better idea of
   >of the scale of this inefficiency.

   The database was approximately 80 Megabytes or so.  We were close to
   filling up a 100 meg disk.  This inefficiency has been demonstrated
   to be the same across two different platforms that I've seen it run
   on. 

I also worked with 9-Track tape drives on Honeywell systems, Ultimate
to be exact and I never say any even close to what you have described
here. An 80MB disk was in the neighborhood of 1.5 hours. Maybe many of
your files were VERY poorly allocated with a large number of extents?

-- 
____________________________________________________________________________
Mark B. Booker  Customer Support Manager    |  mark@jtsv16.jts.com
J.T.S. Computer Systems Ltd.                |  uunet!jtsv16!mark
Toronto 416-665-8910 FAX 665-8258           |  ...![sun!]suncan!jtsv16!mark
