Usenet.com

www.Usenet.com

Group Index

Comp Thread Archive from Usenet.com

<-- __Chronological__ --> <-- __Thread__ -->

Re: Dreaming About Redesigning SQL



[EMAIL PROTECTED] (Bob Badour) wrote in message news:<[EMAIL PROTECTED]>...
> [EMAIL PROTECTED] (Paul G. Brown) wrote in message news:<[EMAIL PROTECTED]>...
> > Lee Fesperman <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> > > 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.

  Trouble with the old reading comprehension again, eh Bob?

  Have another look at what I typed. See the semi-colon? Two relations. Two 
  "structures", the attributes of which are unambiguous. 

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

    None. But that's not the point. Pleas read the carefully quoted text 
    from the previous posts. 

    Where do I sign up to get back into your twit-filter? 

    KR

              Pb



<-- __Chronological__ --> <-- __Thread__ -->


Usenet.com



Please check out one of the premium Usenet Newsgroup Service Providers below for access to Usenet.