Re: A question for Mr. Celko

Marshall Spight wrote:
>> 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.

Do all values in the RVA column have to have the same columns? i.e. is there just one RVA type or a different type for each relation that has a different column setup?

In first-order logic your variables can only be values, not predicates. If you have RVAs that the RDBMS "understands" then you are going to have variables that are relation-valued ie. predicates.

Now this isn't a problem if you are just storing the relations as an "encoding" that is invisible to the RDBMS, but once you let the RDBMS see the structure of your RVAs directly it jumps from being a value to being a predicate.

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

so that breaks the symmetry?
some are relvars, some are relation-values.

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

OK then, how does a view created in this way differ logically from a standard view created by merely JOINing the two tables?

e.g. tuples using RVA:

(1, 'Fred', {('a', 'apple'), ('b', 'banana')}) (2, 'Bill', {('c', 'cherry')})

vs. tuples from a view of persons JOIN fruit:

(1, 'Fred', 'a', 'apple')
(1, 'Fred', 'b', 'banana')
(2, 'Bill', 'c', 'cherry')

('a', 'apple', 1)
('b', 'banana', 1)
('c', 'cherry', 2)

The point I'm making is what does the RVA-view give you that the standard view doesn't?

Could you give a concrete example of where you think a RVA would be useful?

I'm thinking for example of an invoice table that stores invoice lines in a RVA in each row Pick-stylee, but I think this might not be the kind of application you have in mind.

Because the problem in this case would be you are taking your single logical relation-value and splitting it up into multiple smaller relation-values, one for each invoice.

You're also losing the invoice-line relvar and kind of incorporating it within the invoice relvar.

I've no problem with RVAs in general, I just think that RVAs should exist in a separate "universe" (no pun intended) to real relations.

Paul. Received on Sat Jul 24 2004 - 18:45:54 CEST