Boost logo

Boost :

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-03-16 17:54:30


Thorsten Ottosen wrote:
> Rene Rivera wrote:
>> Sure... But we could use that same argument to propose that we write C++
>> programs by writing an abstraction on top of C++ compilers in Python so
>> that we can remove the incompatibilities in the various C++
>> implementations.
>
> I guess you could do that. Like C++, porting can be a major problem.
>
> Note, however, that is not an argument against having portible SQL DSL.

True :-) But it's an argument that a portable SQL DSL is not a great
advantage.

>> Having had the displeasure of dealing with PL/SQL there
>> is one serious drawback to the language embedded approach, it ties ones
>> to the capabilities of the abstraction.
>
> Right. The SQL library should provide a backdoor so you can still use
> string queries if you need to be non-portable or cutting egde etc.
>
> I some of our company tools, we support multiple server backends: at
> least oracle, mssql and mysql. I'm surpised just how diffucult it is to
> write portable SQL (even for very very simple queries).
>
> If you want to use different functions, there's a pretty good change
> they are different on different systems. I have end up writing my own
> abstractionlayer in php to compensate.

That drives into what I think is the core problem I have with an SQL
DSL. It doesn't provide an abstraction that has compelling advantages,
other than syntactic sugar. What I would find way more useful would be
an abstraction that removes the SQL language itself, i.e. a relational
database library. That would have some advantages:

* Better coherence with C++ data types.
* Possibility to support non-SQL relational databases.
* Make it easier to construct object/relational translation abstractions.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk