Re: relational tables and objects

Arkadiy Vertleyb wrote:
>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:
>> >> 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.

But the most optimal implementation of a join or a group-by is not always with range queries. What then?

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

After every move you update the precomputed join.

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

Sounds good, but it also sounds like what many object-oriented databases offer.

• Jan Hidders