"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
Sorry to be confused about the target -- I thought there was some discussion of eventual rdb interfaces.
Still, even without the db I think it is very interesting and useful work. Combined with serialization it seems clear
you can clearly create some elegant solutions to tricky problems without
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. that the
weight of a full database system.
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
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. 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