Re: relational tables and objects

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