Home -> Usenet -> comp.databases.theory -> Re: Impossible Database Design?

Re: Impossible Database Design?

From: -CELKO- <jcelko212_at_earthlink.net>
Date: 18 May 2006 17:13:33 -0700
Message-ID: <1147997613.805265.265340_at_j73g2000cwa.googlegroups.com> 






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.



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.



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.




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 - 02:13:33 CEST












Original text of this message