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. -- Marc-Andre Lemburg eGenix.com 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 http://www.egenix.com/company/contact/ _______________________________________________ Zope-DB mailing list Zope-DB@zope.org https://mail.zope.org/mailman/listinfo/zope-db