Re: Can relational alegbra perform bulk operations?

compdb_at_hotmail.com wrote:
> Of course optimizers use algebraic identities to rewrite.
> They just also use other information like size and indices
> to create a tree with some optimized property.
> The biggest time expense tends to be
> secondary storage page access.
>
> It might seem such things have to be implemented as loops,
> but it all depends on your implementing machine.
> Maybe it is a parallel processor.
> If you want the longest stick of spaghetti you just hold
> them all upright on the counter.

Yes, I can easily see how one can select the longest stick of spaghetti and to contrive the analogy a bit, we can slide it through a plate set at a certain height and thus filter out the taller spaghetti, then one more plate at a lower height and discard those that passed the 2nd filter leaving us with spaghetti between x and y. In other words, range seek. Going back to the relvar, it only applies to one relvar (not to say one can't use the same filters for two different relvar under certain condition as Bob provided in his example of customer and state relations being filtered by 'AK' first prior to being joined together.

What I was really interested in learning whether join (or any operations involving more than one relation) could be processed in similar manner without necessitating loops across a set of tuples within a relation to determine what tuples from other relation satisfy the condition. Based on what I'm picking up (and I hope I'm following along) such thing is unavoidable.

> If relational algebra were presented properly you would find that
> first of all it is an algebra schema,
> since every set of types produces a different algebra;
> that those algebras are "many-sorted", the sorts being relations,
> attributes, sometimes attribute lists, sometimes quoted-expressions,
> and the types;
> and that you would have additional operators like
> ONE_BY_ONE_RELATION_type(ATTRIBUTE, value) returning a relation
> and VALUE_type(relation) returning a value of the type.
> (You don't need to have explicit tuples.)

Indeed. Date basically argued that SQL DBMS was lacking in proper type & operator support. A part of reason of why I'm asking those questions is to help me understand how did SQL end up the way it is right now and why relational model wasn't more closely adhered to. I had latched on the notion that it had to do with that relation model (as far as I know about it via Date's book) didn't say much about how to optimize the evaluating of given expression so it's computationally cheaper to process the given expression. Received on Wed Sep 30 2009 - 14:34:39 CEST