Re: Can relational alegbra perform bulk operations?

On Sep 30, 5:19 am, Banana <Ban..._at_Republic.com> wrote:
> Tegiri Nenashi wrote:
> > This is no different from saying that in order to add numbers the
> > addition operation has to look inside the number structure (that is
> > decimal representation).
>
> Thought about that and realized that is basically true of any system;
> the act of evaluation itself requires that we, well, actually discover
> the independent values to determine the dependent values (apologies if
> this is not correct terms to use here).
>
> Going back to the join problem, I think my confusion may have arose in
> conflating the evaluation and the expression. We can write an expression
> that proposes to join an arbitrary number of relvars but we still must
> evaluate the final relvar baed on what tuples satisfies the given
> conditions. Thus there is really no way around doing joins without some
> kind of evaluation and evaluation is necessarily iterative. Not to say
> that we can't make use of index and other techniques to save ourselves
> the trouble of needlessly evaluating tuples that wouldn't have made into
> the join anyway, but when left with only tuples that may or may not be
> an eventual participator in the join each must be evaluated.
>
> In former sense, we do have a 'sieve' in forms of indices, cost-based
> optimization/transform, restricting the evaluation to only possibly
> relevant tuples but the 'sieve' wasn't provided by the relational model,
> and after filtering through the 'sieve', one still must evaluate the
> individual tuples to generate the resulting output.
>
> Is my description accurate now?

Yep. Minor correction: the 'sieve' wasn't provided by the relational algebra. Relational model, however, does refer to tuples, so, from definition of join in set notation, for example, one may infer nested loops algorithm. Received on Wed Sep 30 2009 - 17:56:02 CEST