Re: A question for Mr. Celko

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.

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

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?

If it's a relvar then what if you try to set it equal to the relvar it's contained in? Should its name be held in the system tables of the DBMS?

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

> 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 think that the practice of including "system tables" in the same DBMS 
as your actual data is a similar thing that confuses the issue and the 
difference between data and metadata. I think it's actually one of 
Codd's requirements for a RDBMS that system tables be included but it 
seems wrong to me. I think they logically belong in a separate DBMS (not 
just a separate database). But then I guess that would need *its* system 
tables to be held separately and so on ad infinitum. So maybe "system 
tables" shouldn't be held in a DBMS at all.

Paul.