Re: Pizza Example

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Wed, 07 Apr 2004 15:04:19 +0200
Message-ID: <4073fc51$0$570$e4fe514c_at_news.xs4all.nl>


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?

> 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?

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.

> 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.

> 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? Received on Wed Apr 07 2004 - 15:04:19 CEST

Original text of this message