Re: Pizza Example

From: Eric Kaun <>
Date: Mon, 12 Apr 2004 16:02:30 GMT
Message-ID: <p4zec.53523$>

"Dawn M. Wolthuis" <> wrote in message news:c51s04$clg$
> 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? If so, what does it mean if I pass an ID like SS# = 123-45-6789 more than once? Or do you mean you can pass sets of lists? And if you do query for child name (for example) = {"Sam", "Max"}, is that treated as an OR or an AND?

> > And yes, relation-value attributes are a sound logical basis for both
> > reporting (e.g. "parent/child" reports) and outer joins - killing two
> birds
> > with one stone, if only the language support were there...
> yes, it is almost enough to bring me back to relational theory if the
> implementations of the model didn't push me away again

It's a little difficult to argue with someone doing the non-relational "thang" when the existing SQL implementations are so lousy. Hopefully y'all will give Dataphor a try (though I have to myself), or another one (assuming more come along).

> > > PICK idenfies whether data is physically stored or is
> 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.

> Some might think it unfortunate, but logical dictionaries for a file could
> describe all stored data or only derived data or any combination. AND,
> 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?

> > I'd say it makes reporting data easier, at least as long as the
> multi-value
> > attributes are only used for display. Most such attributes I've seen
> > to acquire "intelligence" (e.g. establish themselves as more complex
> > propositions), make a relation for them almost a foregone conclusion.
> Although one could say that about just about any attribute, whether single
> or multi-valued. We could put each in a separate base table with foreign
> keys and all ... sorry for typing that, but ... smiles. --dawn

Actually, if you do a search for "binary relations", you'll find something just like that - a model where every relation is a pair: (key, value), where value is for a single attribute. Constraints are then required ("even more so") to maintain the consistency - in effect combining binary predicates into N-ary ones. The N-ary ones communicate better to people, of course, but are equivalent (I believe - I'm no expert) to the binary ones plus constraints.

  • erk
Received on Mon Apr 12 2004 - 18:02:30 CEST

Original text of this message