Re: Dreaming About Redesigning SQL

paul_geoffrey_brown_at_yahoo.com (Paul G. Brown) wrote in message news:<57da7b56.0310080006.47b550a9_at_posting.google.com>...
> Lee Fesperman <firstsql_at_ix.netcom.com> wrote in message news:<3F833025.76A6_at_ix.netcom.com>...
> > Jan Hidders wrote:
> > >
> > > Seun Osewa wrote:
> > > > I would also like to know the classical arguments against the network
> > > > model or other "pointer based" models. The only things I know are
> > > > that:
> > > >
> > > > ** using pointers to positions in memory or disk can be messy when
> > > > data has to be moved around. But then is seems there are several
> > > > simple ways to solve this, e.g. what I can only call "logical
> > > > pointers".
> > >
> > > Correct. There's absolutely no reason to believe that you cannot have
> > > data independence with logical pointer or references. I would however
> > > argue that allowing entities without representable keys is not a good idea.
> >
> > Incorrect. Even though you call them 'logical' pointers, they are still physical
> > artifacts and have no place in a truly logical view of the database. Databases are about
> > data, and pointers are not data (or meta-data).
>
> Erm . .
>
> What's 'physical' about this?

Retrieval implies a physical operation, but a name is just a name after all. Having two attributes called name in a single structure requires physical location to disambiguate.

> RELATION Dept ( Id Dept_Id KEY, Name String );
> RELATION Emp ( Id Emp_Id KEY, Dept REF(Dept),
> Name PersonName, Salary Money );
>
> RETRIEVE E.Name, DEREF(E.Dept).Name FROM Emp E;
>
> RETRIEVE E.Name FROM Emp E, Dept D
> WHERE DEREF(E.Dept).Id = E.Id AND D.Name = 'shoe';

Whether physical or not physical, the pointer is a superfluous structural element. Other than increasing complexity, what purpose does it serve? Received on Thu Oct 09 2003 - 02:52:32 CEST