Re: relational tables and objects

From: Dm. Arapov <darapov_at_cox.net>
Date: Fri, 01 Nov 2002 04:08:45 GMT
Message-ID: <h7nw9.77929$vq2.2152799_at_news1.east.cox.net>


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

> Dm. Arapov wrote:
> >"Jan Hidders" <hidders_at_REMOVE.THIS.uia.ua.ac.be> wrote:
> >>
> >> Just for my understanding, your library doesn't provide persistency,
does
> >> it?
> >
> >The library neither provides persistency, nor prohibits it. It is
> >parameterized with a class, which function is to provide implementation
of
> >tables. [...] Our design goal was to allow users have their own
> >implementations of tables and indexes. RTL makes possible to have
different
> >implementations for different tables. [...]
>
> Ok. But would I then not also have to override/reimplement the relational
> operators (like GROUP BY or JOIN) to take the specific implementation into
> account?

No, there is nothing to override there. Both operators are ready to use. (You can specify your own groupby functor, of course) Actually you can even use default table implementation, if you are happy with sorted vectors.

>
> >>in almost all cases a more specific data structure will perform better.
> >
> >Sure. It is an axiom, that in assembly language everything can be coded
to
> >perform better. It simply takes too long to tailor specific data
structure
> >for each case.
>
> Axioms usually don't have empirical evidence. :-) But your argument works
of
> course in both ways. Why would I use this library if I can use RDBMSs
> without the need of filling in templates or defining derived classes?

If you need full-scale DBMS, then you'll better use one. RTL is to help people with small needs.
Say, inside a strategy game programmer needs to join tables, describing units positions, and then perform actions based on resulting relation. Sure, the programmer can code this using any DBMS. However, calling ODBS to store tables (no persistence is required),
passing SQL statement (no ad hoc queries expected) will take long time. Other problem is to store objects. Classical DBMS operate limited number of types, so
C++ programmer will need to code some mapping of classes to tuples. After all, one need to deploy the engine with the application, which also have some drawbacks.

In other words: "Do you need an 18-wheeler to ride to a grocery?"

Other way is to use STL conatiners and code manulally merge or nested-loop join. Sure, it is not big deal, but still requires time. RTL was designed to save it.

Dm. Arapov. Received on Fri Nov 01 2002 - 05:08:45 CET

Original text of this message