Re: Pizza Example

From: Anthony W. Youngman <>
Date: Mon, 19 Apr 2004 21:33:28 +0100
Message-ID: <>

In message <2HQgc.9747$>, Eric Kaun <> writes
>"Anthony W. Youngman" <> wrote in message
>> In message <HLyec.53517$>, Eric Kaun
>> <> writes
>> >> I want my cake and eat it too! The PICK structure does what I have
>> >> described and is "amenable to automated deduction" and it seems to me
>> >> there is some value in that, but I'm still poking and prodding to
>> >> what that might be.
>> >
>> >Of course it's amenable, just much less so. It's its lack of symmetry and
>> >consistency that poses a problem. By nesting values inside values (and
>> >a further layer inside that, I believe), you complicate the algebras,
>> >closure, and optimizations. Relational is much simpler, hence its power.
>> Define "simple".
>Good question; in this case I meant simple as advocated by Occam's Razor.
>Fewer concepts, and more consistent notation.

Occam's razor - as phrased by ?Einstein - "Things should be as simple as possible - but no simpler".

To me, relational has simplified too far - "The car is blue and green", "John is Mike's dad". If I model both these situations in relational, I need a relation to link the colours to the car. I need a relation to link John and Mike. In the first situation I'm linking an entity with its attributes. In the second I'm linking two entities. Relational makes no distinction between the two types of link ...
>> So if I run a query, that gives me a view of a complex object, why does
>> it give me an indeterminate number of copies of a piece of data that is
>> stored just once?
>I don't know what you mean here.

I think I'm confusing relational and SQL here ...
>> Or, I want to find all the attributes of a single, real-world object.
>> With relational, that's a complex query.
>Define "complex." It usually depends on the "object" - oh, can you define
>that as well?

Well, I'd define a real world object as something described by a noun - an invoice, a car, a person ...

Certainly with an invoice, or a person, the relational query could be quite complex with joins across quite a lot of tables.
>> With Pick, it's "here's the
>> (singular) primary key, get the data".
>That's certainly possible in SQL too, just as it's possible to be normalized
>in Pick. However, your statement is just hand-washing, since "the data" is
>what the entire disagreement is about. Is it a set of attribute values? Is
>it an object graph? Is it both, meaning we've decided in advance the view of
>"the object" everyone must have because it's "real world" (can you define

Typically, it's a set of attribute values. And yes, I see what you mean - given the primary key, a relational view will return (after a lot of work if it's scattered across many tables) all the attributes associated with an entity. With Pick, it is a single "row" in a single "table".
>> As I said, define "simple" :-)
>> As for saying "it complicates the algebra...", WHY? It makes it easier
>> to do stupid things, but it doesn't affect the algebra and, indeed,
>> despite making it easier to be stupid, in practice it seems to make it
>> less common.
>You have separate notation for values, sub-values, sub-sub-values, ...
>sub^N-values, whatever N is (once I heard 3, once I heard 6).
Well, yes, the fact that in relational N is only ever 2 makes life simple. But that's a "cosmological constant" which upsets purist physicists. If I can solve a problem for N where N is any number, it's a far better solution than if it only works for "N=2" :-) (and actually, both the values you've quoted for N I've met in practice :-)


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
Received on Mon Apr 19 2004 - 22:33:28 CEST

Original text of this message