Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!wuarchive!uunet!merk!uvmark!jim
From: jim@uvmark.uucp (Jim Todhunter)
Newsgroups: comp.databases
Subject: Re: PICK dbms/os on UNIX
Message-ID: <1991Jun12.234525.32586@uvmark.uucp>
Date: 12 Jun 91 23:45:25 GMT
References: <1991Jun10.223018.26414@ringer.cs.utsa.edu> <10628@idunno.Princeton.EDU> <1991Jun11.224403.9172@ringer.cs.utsa.edu>
Organization: Vmark Software, Inc.
Lines: 26

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:
>>
>>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 correct.  PICK does allow the specification of dictionary items
that reference fields (columns) in other files (tables).  Also, both the
Vmark's uniVerse and Prime's Information products allow virtual field
definitions to include arbitrarily complex (or simple) application source
fragments.  This ability allows one to avoid some of the costly join operations
that must be done when using SQL as an access method.

-- 
 James W. Todhunter, Manager, Software Development
 Vmark Software, Inc., 5 Strathmore Road, Natick, MA  01760, USA
 Internet: uvmark!jim@merk.com, UUCP: uunet!merk!uvmark!jim
 Phone: (508) 655-3700, Fax: (508) 655-8395, Telex: 5101011619 VMARKUNIVERS