Looking for a language/framework

[Scott David Daniels]

Ravi Teja wrote:
>> ... I've never seen an "object-relational mapping" (technical term for
>> cruft that tries to avoid people having to learn and use SQL) which
>> doesn't drive me into a murderous, foam-at-mouth rage in a very
>> short time -- I *WANT* my SQL, I *LOVE* SQL, it's *WAY* more powerful
>> and suitable for access to data than all those simulated "OO DB" people
>> lay on top of it....
> 
> I for one don't have any particular love for SQL. For most purposes I
> don't want to be bothered with its details. However, I am disillusioned
> with ORMs. With SQL and old school database management, I had tools
> such as QBEs, ERD managers to visually manage much of the details (I
> perform better with pictures than text) and even if others disagree, it
> worked well for me. Now with ORMs, I am back to code again. Granted, it
> appears cleaner most of the time but I want to be able to not see it at
> all....

But what you overlook is SQL's strength:

     SQL can be translated into _very_ efficient query plans w/o changing
the SQL.  SQL's query optimizers (more properly, de-pessimizers) give
performance which can be tuned w/o touching the SQL.  SQL, a language
which is truly ugly, not quite standardized, and otherwise quite clunky,
does manage to let you say more of what you want without specifying how
to get it.  This separation of result spec from query plan is what makes
makes those optimizers work.  The ORMs put objects on top of the DB, but
in a way that either (A) violates the object model in that everything
must be of the _same_ type in a table (good-bye duck-typing), or
(B) gives up on most any attempt to get optimized access -- the DB
becomes a persistent store, without the normal SQL feature of "our DB
admin can tune this up to fly like a peregrine in full stoop."  A
query planner for well-insulated objects just doesn't have enough
information about what it can and cannot rewrite, so it doesn't know
how to estimate how much I/O one plan will cost as opposed to another.

--Scott David Daniels
scott.daniels at acm.org