Re: Pizza Example

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Wed, 7 Apr 2004 11:04:23 -0500
Message-ID: <c518r5$lqk$1_at_news.netins.net>


<snip>
> Over what other operations are Pick data structures closed? Or rather,
what
> Pick operations are closed over its data structures?

Eric -- because there is no such formalization of the PICK structures as there is with relational ones, I'm being very imprecise here to the extent that I would call this an eyeballing feature -- if you write a SQL statement and see the output on the screen, the output is 2D and includes repeating data.

For example: SELECT NAME, MAJORS FROM STUDENT_MAJOR_VIEW;

might yield

Davy Jones Philosophy
Davy Jones Mathematics

There is no base table that is modeled with the name "Davy Jones" stored in it twice, but a query on the view yields this output.

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". Queries on these yield results that look just like base tables. The user just asks for fields from a given file -- the data could come from anywhere (which is why I call the file descriptions views -- they would not be considered such from a SQL standpoint). If you ask for the same data from a PICK file that we requested above you might ask: LIST STUDENTS NAME MAJORS to get

Davy Jones Philosophy

                    Mathematics

The output looks like one record, just as the input for this information was one entry from the end-user perspective. Obviously one can do gyrations and have output from a relational database imitate the natural PICK way of doing things, but it is not the natural way that SQL/relational databases handle data.

This is just that 1NF thing cropping up again. It seems like such a minor point and yet it can really make a significant difference in how easy it is to establish and maintain data. --dawn Received on Wed Apr 07 2004 - 18:04:23 CEST

Original text of this message