[DB-SIG] Improved support for prepared SQL statements
mike_mp at zzzcomputing.com
Wed Dec 17 18:54:01 CET 2014
> 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.
More information about the DB-SIG