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: 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