[DB-SIG] Improved support for prepared SQL statements

[Michael Bayer]

> On Dec 17, 2014, at 10:41 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
> 
> Another possibility is to write a layer on top of the DB-API
> to abstract the underlying queries away from the application
> and only have the layer provide dedicated methods for the
> things the application needs, such as query method for specific
> details or inserting application objects into the database.
> 
> This is the approach we usually take in our projects, since
> it provides better separation of the application logic from the
> database logic than using ORMs usually provides. It's also possible
> to use such an abstraction layer on top of an ORM, if you want
> to the ORM to deal with abstracting away database backend details.

When I read this quickly, it seems to make sense, but when I really try to imagine what this means, I come out at the same place every time: if you’ve written a “method for inserting application objects into the database”, you’ve written an ORM.   Databases don’t store “application objects”, they store rows.  So there has to be “ORM” in there.

>> 
>> I am looking for higher service levels without following the software
>> design directions from object-relational managers like SQLAlchemy
>> and SQLObject.

replying to Markus -

SQLAlchemy’s ORM is only an optional component of the SQLAlchemy database toolkit overall.  If you would like a very mature and well proven SQL abstraction layer that does not provide any design directions whatsoever (not to mention much better performance than the ORM), please consider SQLAlchemy Core: http://docs.sqlalchemy.org/en/rel_0_9/core/index.html.