Re: Dreaming About Redesigning SQL

From: Bob Badour <bbadour_at_golden.net>
Date: 9 Oct 2003 05:33:35 -0700
Message-ID: <cd3b3cf.0310090433.18155e11_at_posting.google.com>


paul_geoffrey_brown_at_yahoo.com (Paul G. Brown) wrote in message news:<57da7b56.0310082228.24530403_at_posting.google.com>...
> bbadour_at_golden.net (Bob Badour) wrote in message news:<cd3b3cf.0310081652.469b1d9d_at_posting.google.com>...
> > 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.
>
> 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.

Apparently, your reading comprehension is once again a problem, because I see no semicolon in the following expression:   ( E.Name, DEREF(E.Dept).Name FROM Emp E )

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

It's my point regardless of any other person's point.

> Pleas read the carefully quoted text
> from the previous posts.
>
> Where do I sign up to get back into your twit-filter?

I suggest you send an email to helpdesk_at_golden.net asking them to fix their usenet service so I do not have to use google groups. You could also propose that google look into providing some sort of twit-filter. Received on Thu Oct 09 2003 - 14:33:35 CEST

Original text of this message