Re: A question for Mr. Celko

"Paul" <paul_at_test.com> wrote in message news:410119f7$0$44434$ed2619ec_at_ptn-nntp-reader02.plus.net...
> Marshall Spight wrote:
> >>The way I see it, to the relational engine, all values are just black
> >>boxes. When it needs to perform some non-relational operation on some
> >>values it just passes the problem on to the type engine.
> >>
> >>Now in the special case where the type itself is "relations", the type
> >>engine has its own little RDBMS that it uses to perform relational
> >>operations within the context of the type. But this RDBMS is logically
> >>totally separate to the orginal external RDBMS. i.e you shouldn't be
> >>able to join a relation-value with a "real" relation in your main RDBMS:
> >>the only communication between the two should be via the type engine.
> >
> > Why? Why have this restriction? What does it buy you? It certainly
> > reduces your expressiveness.
>
> What it buys you is the ability to stick with first-order logic I think.
> Once you've jumped to higher-order logic things are a lot more complex
> and some nice results no longer hold etc.

I used to agree that this is a jump to a higher order, but I don't think that any more. I don't see anything about RVAs that's incompatible with FOL.

> It also breaks the symmetry of all relations being equal which rings
> warning bells.

I don't think it does that either.

> It would be nice to have a concrete example of where this could get you
> into trouble but I can't think of one at the moment.
>
> Is the RVA a relation (value) or a relvar?

A relation value. It's certainly *not* a variable embedded inside another variable.

> If it's a relvar then what if you try to set it equal to the relvar it's
> contained in?

If that were a legal operation, you would certainly be outside of FOL, and you'd be running smack into all kinds of paradoxes.

> Should its name be held in the system tables of the DBMS?

[waves hands]

> If it's a relation-value then that makes it different to the relvar it's
> contained within.

Sure.

> > Let's compare an RVA with a separate table with a foreign key back
> > to the first table. They are informationally equivalent. Why bother
> > to distinguish between those two cases? Why allow some operations
> > when it's structured one way but not the other, isomorphic way?
> > Why not treat the two ways as two views on the same data?
>
> From an engineering perspective, suppose you have a RVA as opposed to a
> separate relation with a foreign-key constraint. Then a bit later you
> find you need to add to your database another relation that needs to be
> JOINed to the relation inside the other one.
>
> You'd have to change over to using the separate-table method.
> So RVAs lose you the flexibility of being able to have your "inner" or
> lookup relation JOIN to several other relations in the future.

I'm saying there is no "change over". The two ways of thinking about the two relations are *views* onto the *same data*. Both views can be present at once; there's no need to choose between one way of thinking about it vs. the other.

Marshall Received on Sat Jul 24 2004 - 04:19:16 CEST