From: Calum Grant (calum_at_[hidden])
Date: 2005-10-20 15:42:46
> > The solution I have is not terribly elegant from RML's
> point of view,
> > since as I said before RML is designed for logical queries
> rather than
> > numerical computation. It was not a terribly interesting problem
> > because it needed just a single table with two indexes.
>
> Hmm, I managed to program it in RTL as a single relational
> view on the original table, without doing _anything_ by hand.
> The correctness of this view is preseved by the library when
> the data is changed. In your case _you_ remove 1982 items.
> In my case _the library_ removes 1982 items. I think your
> solution is rather by-hand than RML-based.
>
> Can you create a single RML query on the original table that
> solves the problem? Can you claim that using RML added a lot
> to your solution? Is it faster/more elegant/readable/etc.
> than just using STL directly?
You make a very fair point. This problem does not lend itself very well
to RML's queries. RML's queries are much simpler, and therefore need to
be glued together with C++. But even so, even these simple queries make
it easier to access data in the table, and the test was exercising the
library. But my line-count was 243 lines, yours was 214, so it's not
such a huge difference.
I frankly have no idea how I would implement that problem in SQL, but
then this was a problem you chose to be very difficult to solve using a
SQL notation. But that does not of course mean that SQL is a bad
approach for other things. Even so, it is extremely interesting to see
how far one can take RTL's queries. And it looks like considerable fun!
I would like to test a database-style application. I feel RML's
notation and design would be much better suited to that type of problem.
Regards, Calum