Re: Pizza Example

From: Anthony W. Youngman <wol_at_thewolery.demon.co.uk>
Date: Sat, 17 Apr 2004 23:19:51 +0100
Message-ID: <ThjjDhCH2agAFwbW_at_thewolery.demon.co.uk>


In message <c5efl5$eel$1_at_news.netins.net>, Dawn M. Wolthuis <dwolt_at_tincat-group.com> writes
>"Eric Kaun" <ekaun_at_yahoo.com> wrote in message
>news:p4zec.53523$gP6.17734_at_newssvr16.news.prodigy.com...
>> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
>> news:c51s04$clg$1_at_news.netins.net...
>> > The way that PICK query statement piggy back on each other is through
>what
>> > are called SAVEDLISTS or SELECT LISTS where you can select sets (yes, in
>> > this case precise) [or occasionally bags] of identifiers (key values or
>> > values of any other attribute) that are then "passed into" any other
>> > statement (without its knowledge) thus narrowing down the records that
>are
>> > available for the query.
>>
>> By bag do you mean a set with true duplicates?
>
>yes
>
>> If so, what does it mean if I
>> pass an ID like SS# = 123-45-6789 more than once?
>
>I don't actually recall whether dups are ignored or whether they are "in
>there" multiple times -- it is not a common thing to do.

SELECT FILE SAVING FIELD [UNIQUE] If you add the "UNIQUE" keyword you get a set, if you don't you (may) get a bag.
>
>
>> > > > PICK idenfies whether data is physically stored or is
>> virtually-defined
>> > at
>> > > > the field level, not the table/file level. So, all descriptions of
>a
>> > file
>> > > > are "views".
>> > >
>> > > But isn't there usually a primary one?
>> >
>> > No -- there is no way to identify any primary one if there are n logical
>> > "dictionaries" for a file. You might guess that if the dictionary name
>is
>> > based on the file name, then that one might be the more heavily used,
>but
>> > maybe now.
>>
>> I would venture that in 99% of cases there's a primary one, at least for
>any
>> one given field / attribute. Otherwise your data truly has multiple
>> meanings, and that can get very hairy trying to serve more than one
>> master... not to mention confusing.
>
>Yes, typically it is easy to tell what the primary dictionary for a file is,
>but, in theory, there is no such thing as a primary dictionary. The
>dictionary is descriptive, not prescriptive, and has such things as a
>display length for a data field. So, even when there is a single
>dictionary, there might be multiple definitions for a single field -- one to
>display the field as left justified text and another to display it as right
>justified numbers (for example for an all-numeric idenfier field). If you
>use one, you have numeric operations you can apply to that field, while if
>you use the other you are working with character functions.

In Pick, the dictionary is just another "table". A FILE consists of a data portion and a dictionary portion, and *both* are optional (although a FILE consisting of just a dictionary is pretty pointless :-)

And you can have multiple FILEs all sharing the same dictionary portion (we do as a matter of course), or multiple FILEs sharing the same data portion (which would fit Dawn's "M and T card" example). It's also possible to define a default select in a dictionary portion so that normal access to the T file would only ever select T records.

This is naturally carried to its obvious conclusion. Relational says you use the same operators to access the dictionary as you do the table. Pick says that the dictionary is, at a fundamental level, indistinguishable from data, with the result that the master dictionary (which I know as the FILE called DICT.DICT) is self-referential - the data and dictionary portions are one and the same.
>
>> > Some might think it unfortunate, but logical dictionaries for a file
>could
>> > describe all stored data or only derived data or any combination. AND,
>> they
>> > could be used (rarely these days, but there are plenty of 20 year old
>PICK
>> > applications IN USE today) something like card decks were in the old
>days
>> > (but without the field lengths) where you have an "M card" and then a "T
>> > card" so that I know of a popular PICK application that holds people and
>> > companies in the same, uh, file on the disk using separate schema
>> > definitions (logical dictionaries).
>>
>> With an attribute that defines what a given record is? How would you avoid
>> looking at a people record using a company schema, and vice versa?
>
>Yes, that is where some of the very old-fashioned "M Card" thinking comes
>in - there has to be a way to tell that is stored so that you can read the r
>ecord and then determine what "template" (dictionary) to apply to it. This
>could be useful in cases such as one that someone mentioned a while back
>where you want to store "drafts" of the data until it is finally cleaned up
>enough to "publish" it as the actual data. You don't want to apply a
>template that treats a number as numeric until you know the data is cleaned
>up to that point, for example.
>

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999
Received on Sun Apr 18 2004 - 00:19:51 CEST

Original text of this message