Re: Dreaming About Redesigning SQL

Lee Fesperman <firstsql_at_ix.netcom.com> writes:

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

But references (as opposed to pointers) are not that far off from surrogate keys, at least in terms of how they can be used to enforce referential integrity. But don't take that as trolling, I'm just setting the stage for a few questions below.

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

I agree with that, and the same is true of references - they do represent a bond between objects, which makes them inflexible. But if you compared an RDBMS that used surrogate keys to establish RI between two tables, you've got a certain inflexibility there as well. If there is no longer a relationship between the two tables, the FK should be dropped along with the RI constraint, right?

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

The only benefit I've come up with is the case where something other than a surrogate key is used as the fk (like state postal code, for example), eliminating the need to do a join to get a meaningful value. What other benefits do you consider to be lost when references are used instead of values?

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

If I understand you correctly, I disagree with this. I understand you to say that if a fk makes up part of the pk of the referencing table, and the fk was a reference, instead of a value, the dbms would not be able to enforce the uniqueness constraint on the pk of the referencing table. That is not true about my ODBMS implementation (PyPerSyst). Did I understand you correctly?

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

I don't understand this point. Can you provide a bit more detail about what you mean, or maybe an example? Thanks.

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------