Re: Impossible Database Design?

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Fri, 19 May 2006 08:47:32 +0200
Message-ID: <446d6973$0$31644$e4fe514c@news.xs4all.nl>

-CELKO- wrote:
> Yes, there is some complexity in doing it in SQL, but I can copy the
> code and feel pretty sure about it. Your code will always look better
> in a make-believe language that you do ot have to implement. But I
> find some of Date's code to be problematic. Various arrangements of
> PACK() and UNPACK() produce different representations of the same
> facts, which he considers a problem in SQL, but not in his language.

"different representations of the same facts" and no way to decide on a canonical form.
It looks as if this occurs whenever one tries to capture some meaning, attributed to order per se, in a relational context. You describe several representations of hierarchy in your book(s), but it also happens when the aim is as - seemingly - simple as representing lists: numbered items/successive items (see Marshall Spights' recent question/thread on
"A Logical Model for Lists as Relations").

> I can live with the assumption that time has a starting point -- some
> temporal logic uses that model because time moves in one direction.
> But I cannot see time with a pre-determined end point.

There is no smallest or biggest number.
Most representations do have them. Very similar, no?

> The one that really got me, however, was some charts in the back of the
> book where one axis is parts (P1, P2, etc.). He puts them into
> intervals, just the way he does Chronons. Parts are discrete and
> keyed by a nominal scale, and are not continous or dense. If you stop
> and look at it, this is a multi-value DBMS model, not a relational one.

MV resticted to sets. The representation does not immediately show that, though.

> And time is a bitch to work with by its nature-- remember the old kids
> math puzzle Ïf a hen and half can lay an egg and half in a day and a
> half, then how long does it take for ..?"
>
>

>>>Date's approach seems completely reasonable to me.  After all, we are dealing with computers, right?  The best we can hope for are acceptable

>
> representations of continuous systems. I mean, is there really a need
> to handle a time interval as an infinite number of instants? <<
>
> No, not as an "infinite number of instants", but as a continuum, which
> is very different. A continuum has no points, so everything is an
> interval. This is what explains Zeno's paradoxes. This is a model,
> not an implementation. What we should have done in SQL was require the
> (start,end) model instead of points in time either directly or by
> implication
>
Received on Fri May 19 2006 - 01:47:32 CDT