[boost] Re: Re: Re: RTL status -"help wanted". Was: LibraryProposal:database (boost::db)

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2004-10-16 14:04:11

"Jeff Garland" <jeff_at_[hidden]> wrote

> Sorry to be confused about the target -- I thought there was some
discussion
> of eventual rdb interfaces.

I may be wrong -- there were some thoughts about providing some static ODBC
wrapper, so that an SQL query could be represented as an RTL relation.  In
this case it could be combined with real RTL tables/relations using RTL
operations.  Of course this is not useful to, say, join two real database
tables, since in this case you want operation performed on the server.

> Still, even without the db I think it is very
> interesting and useful work.  Combined with serialization it seems clear
that
> you can clearly create some elegant solutions to tricky problems without
the
> weight of a full database system.

This really was the idea.  Considering ever growing amount of RAM, many
applications could switch to in-memory databases.  Also, the relational
algebra could be applied to applications that don't really want the overhead
of a real database.  Providing C++ - style in-memory relational database,
with all the typesafety and with no type limitations is the goal of RTL.

A few months ago I had a discussion at comp.object, where I tried to
introduce the RTL, hoping people can think of some unexpected solutions that
can be derived from combining OO and relational approaches.  But it seems
that people are very much polarized.  Most OO people don't want to consider
an RDB for anything other then persistence.  And most relational people
don't really think C++ is the correct way to go anyway.

I think relational algebra is a very good mechanism when you want to share
data, and provide different views of it (that's why it is so popular in huge
systems).  Since the language (relational relational algebra) is so simple,
it's possible to introduce as much redundancy (indexing) as one wants (at
any level of a relational expression -- not only tables) and maintain this
redundancy automatically and efficiently as underlying tables are changed.
That was the goal of our second stage of development, and we've done this.

> That said, the level of interest is not as high as the interface to actual
> RDB's -- because once you start using an actual RDB you want to defer the
join
> logic etc into the database engine itself and are mostly concerned with
the
> resulting data and mapping it to C++ types, etc...

Yes, but again, do you always really want to use that RDB or you just don't
have alternatives?

Arkadiy