Re: Pizza Example

In message <4073fc51$0$570$e4fe514c_at_news.xs4all.nl>, mAsterdam <mAsterdam_at_vrijdag.org> writes
>Anthony W. Youngman wrote:
>
>> ...
>> Why not? If you're talking about a Pick schema, then the only reason
>>you can't get a relational model is if the Pick designer didn't do
>>his job properly.
>
>The example FILE ORDER_ITEMS only supports the data for one partial
>process: take an order for a pizza (or a pizza-like thing such as
>Garlic bread). It doesn't, for instance, support the data for taking
>Neapolitan Ice Cream orders as pointed out by Laconic2.
>
>What would a Pick-schema look like that would support Ice Cream orders?

Let's say I wanted to keep ORDER_ITEMS, rather than create a new ICE_CREAMS FILE, I would probably have two FIELDs in ORDER_ITEMS, the first called BASE and the second TOPPING.

I would need a lookup-file containing permitted bases, which might contain the records "ice cream", "thin pizza", "crusty pizza", etc. I'd also have a lookup file of permitted toppings, and the matching bases, so I'd have records like "fetta; thin pizza, crusty pizza", "chocolate; ice cream".

Okay, validation is being pushed into the app layer (I'd like triggers to enforce it when the app tried to write to the database), but if my toppings file is indexed on the "matching base", the app would present the user with a list of bases for the ORDER_ITEMS. As soon as they have selected one, I read the index to get a list of permitted toppings which I can then present to the user for selection.
>
>> As a Pick database designer, I would have one FILE (our equivalent of
>>"table") per real-world object type.
>
>Even if there would be support for Icecreams and wine it wouldn't
>be even close to re-use of those data by other
>applications/processes/use-cases, let alone sharing data
>between them.
>
>From this I get the impression that the Pick view on the term
>"database" is a sort of deluxe filesystem for one application
>instead of a shared repository. Is that correct?

What do you mean? You mean you'd describe a hard disk as a deluxe filesystem for a single application called "the operating system"?

Actually, Pick did start as a sort of operating system, so it would be more correct to view it as an environment where you can run multiple applications on it that share their data. So as I see it, it *must* be a "repository", or database.
>
>I am not suggesting this is a wrong view, it just a different
>type of beast than what I have in mind when I use the term database.
>A databases (as I use the term) by definition contains shared data.
>As a consequence the database (schema) should be designed to support
>mutliple applications.

Yup. Pick is.
>
>> As a Pick database designer, I would have one FILE (our equivalent of
>>"table") per real-world object type. The data in this file *is*
>>*normalised*. It's just that it's NFNF (non first normal form).
>
>Could you please elaborate on the normalisation as you use the term?
>A google on 'Pick Normalise data' doesn't help much.

I use it as I understand everyone else uses it - you analyse your data to remove redundant repetition. It's just that, as far as I am concerned, "normalised" does not mean "*first* normal".
>
>> So. Imagine you've defined a view, in your relational database, that
>>joins all tables representing an object. You then "list" (sorry I
>>don't know the relational term) one object in your view. In your
>>two-dimensional view, imagine that all duplicated values just "don't
>>exist". You now have the equivalent of a Pick RECORD (a bit like your
>>row). We don't duplicate a simple attribute because it doesn't make
>>sense to do so - why list it repeatedly when it only exists once per object?
>
>ISTM that this is a reporting issue. Is there more to it?

See my other comments. Dawn has said I'm confusing relational and SQL (which is likely true). If you select a view that includes a "many" join, then the view will likely contain redundant repeated data.

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