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++
> 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
>> 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, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk