[DB-SIG] Re: Database Abstraction in Python

M.-A. Lemburg mal at egenix.com
Mon Apr 18 14:56:27 CEST 2005


Please don't use the term "DB API 3.0" for anything that
has to do with database abstraction.

The Python DB API has a different scope. It is a driver interface
specification, not a specification for higher level interfaces.
The latter can easily be built on top of the DB API and there
have been a few successful attempts to do so:

PyDAL started by Randall Smith last year:

    http://pydal.sourceforge.net/

ADOdb which was originally written for PHP:

    http://adodb.sourceforge.net/

SQLObject which is an ORM layer on top of the DB API:

    http://sqlobject.org/

PDO, an OO API similar to ADO built on top of the DB API:

    http://pdo.neurokode.com/

(probably others which I don't remember)

If you want to start a new project in that direction,
please have a look at the above projects first and see
whether one of them fits your needs.

The next version of the DB API spec will not include any
of these abstraction attempts, but instead focus on
clarifying the DB API 2.0 and possibly moving some of
the currently optional features in the spec to the
mandatory sections.

The DB API's aim is to provide a solid and
working basis for the many possible abstractions which
are commonly used in database programming, from general
purpose abstraction layers to per-application
implementations.


That said, please note that my recommendation to Tom
Haddon is based on my own experience in Python database
programming. I've done quite a few of these abstraction
interfaces on top of the DB API in many projects and
found that you get much better portability if you
implement the abstraction based on the application
rather than going for an abstraction of the abstration
which is bound to have to make compromises one way
or another.

Given that the application writer usually knows best
what she expects from the database and which database
backends she intends to tagret, the per-application
abstraction interface has usually turned out to be
the best choice in terms of flexibility, robustness
and performance. It also makes it easier to adapt
the application to various backends - hiding the SQL,
matching the database data types to application
data types and tweaking varying database semantics
to fit the application's needs.

Again, that's my experience. YMMV.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 18 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