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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk