Chris Withers wrote:
> M.-A. Lemburg wrote:
>> I'd suggest to use a Python class as abstraction layer
> Sounds like an ORM to me ;-)
No, there's no "object-relational mapping" being done, only
interfacing between the data used by the application and the
schema you have in the database.
As nice side-effect, you can also add business logic to the
abstraction layer, optimize queries to partly run in Python
and in SQL, reorder your SQL to tweak the database optimizer into
writing good access plans, etc.
> Seriously, SQLAlchemy lets you do all of the things you're worried
> about, performance and flexibility wise, as well as map your sql onto
> objects (or not, if you don't actually want objects!) with ease...
> Hmm, I guess what I'm actually saying is that ORM or not is one choice,
> either way, I'd *strongly* recommend using SQLAlchemy rather than trying
> to roll your own abstraction layer of any sort.
If you want yet another abstraction layer between your code
and the database, that's the way to go, yes :-)
SA does provides a general abstraction layer, not the application
specific one I was talking about.
Professional Python Services directly from the Source (#1, Aug 26 2010)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
Zope-DB mailing list