From: Jeff Garland (jeff_at_[hidden])
Date: 2006-04-17 10:53:51
On Sun, 16 Apr 2006 14:26:45 -0500, Rene Rivera wrote
> Steve Hutton wrote:
> > On 2006-04-16, Andreas Pokorny <andreas.pokorny_at_[hidden]> wrote:
> >> 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.
> > However, in practice as a db application developer, I have found some
> > significant advantages of the pure SQL string approach:
> And another advantage. If those queries are structure in the same
> vein as Boost.Format strings they can be changed without modifying
> the handling code. A pattern I've used for DB development is to
> write the program with SQL query clarity in mind first, then go back
> and performance tune those queries. The optimization step would be
> considerably more painful if the program needed to be recompiled
> each time.
There's no doubt to me that the string approach based on my experiences
developing object to database bindings for many of the reasons Steve and Rene
mention -- so I think that approach is should be favored. The main thing for
more is the simplicity of the interface and as both mentioned the use of other
tools to test the SQL queries.
BTW, I think there's a more general library possible here which simply binds
program variable values to string 'templates' or stand-ins -- ala the perl
template toolkit and a gob of others in other languages. With the more
general case you can expand binding beyond sql to say html, etc...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk