Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!ogicse!cvedc!mcspdx!adpplz!martin
From: martin@adpplz.UUCP (Martin Golding)
Newsgroups: comp.databases
Subject: Re: PICK dbms/os on UNIX
Message-ID: <797@adpplz.UUCP>
Date: 12 Jun 91 19:26:05 GMT
Article-I.D.: adpplz.797
References: <10595@idunno.Princeton.EDU> <1991Jun10.223018.26414@ringer.cs.utsa.edu> <10628@idunno.Princeton.EDU> <1991Jun11.224403.9172@ringer.cs.utsa.edu>
Organization: ADP Dealer Services R&D, Portland, OR
Lines: 44

In <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.  

Yeah, you could. Use T (translate) in the correlative or conversion field. 
My (VERY small) experience with SQL is that Pick dictionaries have more
computing power but SQL is dynamic. For reasearch and experiment, SQL
wins easy. For software development, it's a tougher decision.

>>>Working with a 9-Track tape drive on the Honeywell system, it took more than
>>>72 hours to complete a file restore. 
>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. 

This is indeed one of the problems of the Pick database design: the data
itself is hashed into the files. Another database would be faster by the
ratio of the index size to the data size, much faster if the index is
small enough to be cached. 

The tradeoff is the speed with which individual records are accessible:
no file extents, no index blocks, just name.the.address.and.point.

The stuff the Pick system REALLY lacks is transaction management and
crash protection.


Martin Golding    | sync, sync, sync, sank ... sunk:
Dod #0236         |  He who steals my code steals trash.
A poor old decrepit Pick programmer. Sympathize at:
{mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp