Re: relational tables and objects

"Jan Hidders" <hidders_at_REMOVE.THIS.uia.ua.ac.be> wrote in

> Who receives the 'join' message? I mean, if I join A and B do I say
>
> A.join(B)
>
> or
>
> R.join(A,B)

Neither. The simpliest way to join tables is to call join_eq<list_of_columns_to_be_equal>(A,B);

Result of this call will be object of class join_t_eq<TableA, TableB, list_of_columns_to_be_equal>.

When you get the object, you can iterate over it (concept close to CURSOR). The code will look like:

join_t_eq<TableA, TableB, list_of_columns_to_be_equal> jn = join_eq<list_of_columns_to_be_equal>(A,B); for(join_t_eq<TableA, TableB, list_of_columns_to_be_equal>::const_iterator it = jn.begin(); it != jn.end(); ++it)
{

    (*it).do_what_you_want(...);
}

jn looks like collection. But it is VIRTUAL collection, it takes parts of tuples from tables (or other relations) A and B

Dm. Arapov

news:3dc3135d$1_at_news.uia.ac.be...
> Dm. Arapov wrote:
> >
> >"Jan Hidders" <hidders_at_REMOVE.THIS.uia.ua.ac.be> wrote in message
> >news:3dc2b314
> >
> >> But the most optimal implementation of a join or a group-by is not
always
> >> with range queries. What then?
> >
> >This is real question.
>
> As opposed to the phoney ones I asked before? :-) I may sound a bit
critical
> but that doesn't mean I think your library is a bad idea. In fact, it
means
> the opposite. One big advantage that I see is that it anticipates changes
in
> the application. Having an intermediate logical layer helps if your access
> patterns change (new types of queries are asked because the application is
> extended) or if you want to change the storage structure (e.g. you want to
> scale up and now move to disk based storage). If you don't have such an
> intermediate layer the changes to the existing code and data structures
will
> be much bigger.

>
> >Now we have 2 variants of join (merge and nested-loop), range-based and
> >full-scan selections, etc. We plan add new algorithms and are open to any
> >suggestions or help.
> >
> >Now user has to choose, which algorithm is better for given problem.
> >However, C++ compile-time query optimization (e.g. making decision which
> >join strategy to use) is possible in future.
>
> Who receives the 'join' message? I mean, if I join A and B do I say
>
> A.join(B)
>
> or
>
> R.join(A,B)

>
> where R is in instance of your relational engine? Or to put the question
in
> another way, which object has to decide what algorithm is used?
>
> -- Jan Hidders
Received on Sat Nov 02 2002 - 02:11:15 CET