Re: A question for Mr. Celko

Jan Hidders <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message news:<pan.2004.07.21.11.04.38.324586_at_REMOVETHIS.pandora.be>...

> First, there are the domains (d1, d2, ...) and the functions over these
> domains (f : d1 -> d2, g : d1 x d3 -> d4 , ...) and these can be anything
> so the optimizer barely knows more then the signature of this multi-sorted
> algebra. For simplicity we may assume that equality operators and other
> boolean tests are included in these functions.

What about equality and comparison operations between relation-values? For example T1 = T2 is an extremely useful expression, and effectively renders the divide operator unnecessary. And what about existential operators, or set membership operators? The point is there are operators that take relation-valued arguments, but do not return relation values. There may even be operators that take non-relation-valued arguments, and return relation values. I have always thought that relations should be treated just like any other value, at least conceptually, within the query processor. I'm not advocating that relation values should be naively copied around like scalars, but I do believe that query processor implementation would be much more difficult with an architecture that made such an arbitrary distinction between different types of values. Maybe ignorance is bliss here, but our own implementation in this manner has not caused any complexity problems, indeed it has turned out to be an elegant architecture, especially when approaching distributed query processing. Our initial design did make the distinction, but we abandoned the approach when we started to encounter anomalies arising from implementing the two engines differently.

> Second, there is the relational algebra with the usual suspects (but flat
> because we want to stay witin FOL) except we can use the functions over
> the domains. So the selection becomes SELECT[e](R) where e is an
> expression built up from the domain functions and the fields of R, and
> returns a boolean. The projection becomes PROJECT[e1,...,en](R) in a
> similar fashion.

This is the part that is causing me serious reflection. I am no logician, and I'm not even sure I completely understand what constitutes a higher-order logic, much less why introducing operators that can deal with relations with relation-valued attributes is necessarily higher-order.

Thanks for the links, looks like I've got some reading to do.

Regards,
Bryn Received on Thu Jul 22 2004 - 06:11:20 CEST