Re: Dreaming About Redesigning SQL

Paul G. Brown wrote:
>
> Lee Fesperman <firstsql_at_ix.netcom.com> wrote in message news:<3F833025.76A6_at_ix.netcom.com>...
> > Jan Hidders wrote:
> > > 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?
>
> 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';
>
> This schema assumes a strict two-value logic, so Emp.Dept cannot, under any
> circumstances what-so-ever, have anything in it except a 'logical reference'
> to exactly one Dept tuple. How is this achieved under the covers? Who
> cares! It's about the logical model.

I still don't see it as truly logical. It's not data. If you add it to the relational model, you violate the rule about all information being represented as values in tables. Values are -- 14, 'December 12, 2002', "Sales".

But what do I know? Chris Date tells me I'm completely wrong about nulls.

> (I should note that this formulation kind of makes my skin crawl for
> aesthetic reasons, but its a REF()/DEREF() model that is essentially
> syntactic sugar around well understood key and foreign key semantics.)
>
> Not trying to start a flame war, really (though that's an easy thing to
> do when you're as ignorant as I am). I'm just hoping that we can all
> agree that it's the semantics of the model, not the syntax, which we ought
> to care about. 'Logical pointers' (by which I mean this simple REF/DEREF,
> and mindful of a memory I have to the effect that SQL-3 REF/DEREF are not)
> are mappable to PK/FK, and to a wide variety of rules stated in terms of the
> existance of a tuple with certain properties.

Yes, it is mappable to PK/FK but not equivalent.

> The advantage of predicate logic is that there are various kinds of
> rules which can't be stated using REF/DEREF. And when you have a choice
> between two models take the one with the broader expressive power.

Pointers add nothing but complexity. So there's no choice at all.

Perhaps, you'll come around since your file-name pointer argument didn't hold water. A data model that supports references to external entities (like files) not under its control is hopelessly flawed.

-- 
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS  (http://www.firstsql.com)