Re: Pizza Example

Anthony W. Youngman wrote:
> mAsterdam writes:

>> ...What would a Pick-schema look like that
>> would support Ice Cream orders?

As soon as the constraints get a little cumbersome to formulate, the validation is pushed out, the triggers will be implemented in some next release. Yeah right. After the damage is done. It happens to most databases, not just those implemented in Pick-a-likes. The expressional poverty of most DB languages causes this, IMHO.

Date requires the DB language ('D') to be computationally complete. While this would not prevent all this from happening it would take away excuses to not prevent it.

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

No. Why would I do that?

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

Ok.

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

So the restrucuring you proposed for including Ice cream orders affects all other applications. Including the duplicated validations for say the application 'ingredient purchasing'.

>>> 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 am really trying to understand what you mean by normalization or 'removing redundant repetiton'. From this I don't. What normalisation do you mean if not 1..5(or6)NF as described by the relational theorists? That is how I understand everyone else uses the word in a database context. I am not asking you to completely explain the procedure. A reference will do. I'll buy a book if necessary.

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

So for a clean report you would like to have the duplication filtered out.
I would to.
Every dbms I have seen comes with
a reporting facility capable of doing that.

Am I missing the point you make? Received on Sun Apr 18 2004 - 03:15:41 CEST