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