From: Steve Hutton (shutton_at_[hidden])
Date: 2006-04-16 15:18:00
On 2006-04-16, Andreas Pokorny <andreas.pokorny_at_[hidden]> wrote:
> On Sat, Apr 15, 2006 at 08:16:01PM -0300, Felipe Magno de Almeida <felipe.m.almeida_at_[hidden]> wrote:
>> On 4/15/06, Andreas Pokorny <andreas.pokorny_at_[hidden]> wrote:
>> > Slightly offtopic, but what about something like:
>> > using std::sql::select;
>> > using std::sql::from;
>> > auto query = select >> value >> from >> numbers;
> ^ numbers.value of course
>> > typedef decltype(query)::tuple_type tuple_type;
>> > sql::rowset<tuple_type> rows(query,db);
>> > ...
>> > or maybe a more generic reational syntax...
>> I was thinking exactly about something like this. A
>> xpressive/spirit-like way of writing SQL. It should be faster too, I
> I am not sure if it faster, but errors could be detected earlier. If the dsl
> query language is defined generic enough, the query expression could be
> transformed into database specific query strings, or STL/Multindex query
> functors, boost::rtl queries or whatever (during compiletime).
> One would need two separate query models for relational and tree like
> data, to fullfill most needs.
Others have gone down this path, e.g. Rogue Wave db tools. It certainly
has allure as an interesting approach from the perspective of a db
However, in practice as a db application developer, I have found some
significant advantages of the pure SQL string approach:
- SQL queries can be easily tested in a sql query tool during development.
(Using Rogue Wave for non trivial queries, I found myself writing them
in SQL first, testing them, then mentally translating them into C++)
- SQL queries are more readible (again, think queries which join 4 or 5 tables,
multiple conditionals, outer joins, like clauses, etc.)
- SQL queries for an application can be stored in a text file, which can
be easily read by a non-C++ programmer, e.g. a database administrator.
- SQL is an ANSI standard, and it is universally known by every db developer
and database administrator. It is taught in schools and entire books
are written about it.
The SOCI library is firmly based on the SQL approach. That doesn't mean
some other library with it's own query language couldn't co-exist, or
perhaps be layered on top.
But I think having a pure SQL based library in boost would be extremely
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk