[DB-SIG] Database Abstraction in Python

Tom Haddon thaddon at equilar.com
Sat Apr 16 00:11:06 CEST 2005

Hi Marc-Anderson,

Thanks for the response. It sounds like you're saying that the practicalities of database abstraction make its implementation un-pythonic. I'm not sure I fully agree, but I take the point that if you want get the most out of a database, you probably want to write DB-specific code. At the same time, I think the whole point of database abstraction is more from a code re-use/re-factoring standpoint, and that the implicit trade off with features/performance is in some cases worth it.

Appreciate the input though.


-----Original Message-----
From: M.-A. Lemburg [mailto:mal at egenix.com]
Sent: Friday, April 15, 2005 12:38 PM
To: Tom Haddon
Cc: db-sig at python.org
Subject: Re: [DB-SIG] Database Abstraction in Python

Tom Haddon wrote:
> Hi,
> I'm new to the list, so please forgive me if this has been covered before. I searched the archives and wasn't able to find anything, so here goes...
> I'm interested in database abstraction for Python, and am wondering what people use for this. Currently I have thrown together a home-grown class that does database abstraction for MySQL and PostgreSQL for the functions I need, but I realize this is not the way to go long term. I did some google searches and it didn't seem like there was real consensus on what's the best for this in Python. The closest I could see was ADOdb for Python, but since this seems to be a rewrite of a PHP framework, I wasn't sure how good/stable/widely-used it was. Is there a "standard" for this, or is it a matter of personal preference?

The problem with database abstraction is not so much the interface,
it's the different database dialects, data types, stored procedure
syntax, etc. that make this difficult.

To get the most out of the databases that you'd like to support,
it's usually best to write an abstraction layer that's adjusted
to your particular needs and set of database backends.

The generic approach will always have to chose the least common
denominator of all database that it wants to supports. That's fine
for simple applications, but quickly reaches its limits once you
want to do more clever things or benefit from specific database

Marc-Andre Lemburg

Professional Python Services directly from the Source  (#1, Apr 15 2005)
 >>> 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

More information about the DB-SIG mailing list