Re: Pizza Example

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
news: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?

A relational theorist mighy conclude that at first glance. In fact, when I
first saw PICK (which was as a manager after working with "real" databases
prior to that time), I quipped "THAT is NOT a database". However, it isn't
just a filesystem either, although it was used as the native OS for a number
of multiuser computers in the 70's and 80's (some of which are still
plugging along today).

You could see it like this -- software application-centric thinking is that
everything should be done in application software which should then "persist
data" to a repository. Database-centric thinking is that the database could
encompass all constraints and from the database could flow all applications,
based on the specifications in some declarative language. With PICK, you
have no declarative language (for all intents and purposes) but software,
metadata, and data are all blended (even though decoupled) into a whole. So
when someone identifies a DBA in a PICK environment, it is for some very
specific things, such as ensuring that the system (all files, including
those with source or object code, for example) are optimized. These tasks
take a good few minutes a month and an occasional additional effort if there
are problems to debug.

While I thought the approach was old or odd or lacked controls or whatever,
when I first saw it, after having highly productive IT teams working in this
environment, I'm sold -- I wouldn't put my own money into any more
relational database projects if I could help it. I am still very interested
in other non-RDBMS efforts, such as those at sleepycat software and I would
also like to see a better use of constraint/rules repositories throughout
software applications. PICK is not flawless, but highly practical. It is
dated, however, and I'm hopeful that IBM and other PICK providers and 3rd
parties will help address that.
--dawn

> 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:44:36 CEST