Re: relational tables and objects

> >> 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.
>
> So the answer to my question is "yes". Note that the "then" in my question
> referred to "users have their own implementation" in your remark.

Relational operations does not depend on table implementations, they don't know if you use
giant indexed file or it is a vector in memory.

> >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.
>
> In that case precomputing the join and storing it with pointers is
probably
> going to be much more efficient and not much more difficult than modelling
> all the data in the relational model.

RTL allows both variants. If underlying tables do not change, it is possible to store precomputed join result in index, consisting of pairs of iterators (pointers :-)). Otherwise,
if tables changes often, we just perform join each time. RTL does not store intermediate results, however. Say, class join_t_eq, which stands for nested-loop equal join takes only
few bytes of memory. It is a VIRTUAL collection, not a real table.

>What would for
> example be the advantage of using your library vs. simply modelling my
data
> in an UML object schema and implementing those classes. Would that take a
> lot more time? Would the result be less efficient?

UML object schema usually leads to navigational data structures. Such structures are
very common for C++ programmers, but they have drawbacks: it is difficult to implement many-to-many relations and multiple access paths. Maintaining navigational structures in multi-thread environment is also difficult. Relational model proved to be very good for these situations. RTL uses sort order, indexes and range queries to make code efficient. It
uses templates to make manipulations generic.

"Jan Hidders" <hidders_at_REMOVE.THIS.uia.ua.ac.be> wrote in message news:3dc269e3$1_at_news.uia.ac.be...
> Dm. Arapov wrote:
> >
> >"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.
>
> So the answer to my question is "yes". Note that the "then" in my question
> referred to "users have their own implementation" in your remark.
>
> >> [...] 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.
>
> In that case precomputing the join and storing it with pointers is
probably
> going to be much more efficient and not much more difficult than modelling
> all the data in the relational model.
>
> >In other words: "Do you need an 18-wheeler to ride to a grocery?"
>
> Indeed, but the relational model was invented for large shared databases
and
> that is not "driving to the grocery". So the question is why you think
that
> it is appropriate for the applications you have in mind. What would for
> example be the advantage of using your library vs. simply modelling my
data
> in an UML object schema and implementing those classes. Would that take a
> lot more time? Would the result be less efficient?
>
> -- Jan Hidders
>
>
>
Received on Fri Nov 01 2002 - 16:49:06 CET