Re: Dreaming About Redesigning SQL

Jan Hidders wrote:
>
> Lee Fesperman wrote:
> > 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.
>
> Logical pointers can be defined at the logical level and implemented in
> various ways. They are just as much physical artifacts as, say,
> relations are.
>
> > Databases are about
> > data, and pointers are not data (or meta-data).
>
> They carry information. That makes them data. I see no good reason to
> use a more restrictive definition.

Because the information they carry is physical, which doesn't belong in a logical model.

Let me try again:

In the relational model, tables (relations) are completely independent except through the action of inter-table constraints (like referential integrity). The constraints are declarative and truly logical. They can be removed without changing the contents of a single column in the participating tables.

Pointers form a rigid bond between table. To my mind, this makes them physical --- if it walks like a duck, etc.

Pointers don't have the flexibility associated with a logical entity. You must change table contents to remove that bond.

It's been argued here that pointers (references) could be mapped to pk/fk constructs. Besides throwing away other benefits of pk/fk, it doesn't work in the general case, for instance:

+ When the fk is part of the pk of the referencing table,

+ When the fk columns are shared with other fk's.

> > The OP needs to increase his knowledge of database concepts before he
> > tries to 'fix' things.
>
> His motivation may be wrong, but he asks the right questions.

Which makes him a troll (who has lately revealed his agenda).

> > A newsgroup is the wrong place to get any real
> > depth of understanding.
>
> I fully agree. If only because there seem to be so many in these
> newsgroups that confuse "knowledge of database concepts" with "knowing
> what Chris Date et al. say about them". If you want to know what the
> real experts in industry and the research community think, these
> newsgroups are certainly not representative.

Are you saying that someone can be knowledgeable about database concepts without knowing of the enormous contributions made by relational? That is foolishness.

Perhaps, you are attacking Date (I don't know your agenda, though "et al." is revealing). In that case, I agree -- you don't have to read Date to become knowledgeable about database concepts.

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