Re: relational tables and objects

hidders_at_REMOVE.THIS.uia.ua.ac.be (Jan Hidders) 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.

You don't have to override operators. Let's say you have implementation A (in-memory) and implementation B (on disk). A part of an implementation's interface is to provide implementation-specific, efficient range queries based on the sorting order. This, of course, has to be overridden by the table implementor. The relational operators use these range queries on their operands, thus utilizing implementation specific efficient queries. But the operators themselves don't have (and can't) be ovrwritten.

>
> >> [...] 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.

You can't pre-compute your join on let's say, coordinates, if your objects are moving. Which particles hit each other at this moment? You can't pre-compute this.

>
> >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?

We do not intend to be limited with small tables. If there is an effisient, disk-based implementation, we can process large tables. And we are still typesafe, and unlimited with types. Pointers? No problem. Tables inside tables? Feel free. Functors? Monsters? Soldiers? ... What else?

Arkadiy
>
> -- Jan Hidders
Received on Fri Nov 01 2002 - 16:53:26 CET