What are the viable database abstraction layers for Python

Question

I\'m starting to get involved in an open source project Gramps which is exploring switching their backend from BSDDB to a relational database. Either SQLite or MySQL we have

Answer 1

Look very closely at SQLAlchemy.

You can test and develop with SQLite.

You can go into production with MySQL -- making essentially no changes to your applications.

The DB-API, while widely adhered-to, has enough flexibility that (1) you aren't insulated from SQL variation in the underlying RDBMS and (2) there are still DB driver-specific features that are hard to hide.

Another good ORM layer is the ORM that's part of Django. You can (with a little effort) use just the Django ORM without using the rest of the Django web framework.

Use an ORM Layer (SQLAlchemy or SQLObject) in preference to DB-API.

Why? Your model should be a solid, clear, well-thought-out OO model. The relational mapping should come second after the object model. SQLAlchemy makes this a reasonable approach.

A "DB Abstraction Layer" will happen in the normal course of events. Indeed, because of DB-API (as used by SQLAlchemy) you gave two abstraction layers: ORM and DB-API.

Answer 2

CouchDB is not a relational database, so it doesn't have a DB-API interface. It's a document database which means it wouldn't be as useful for Gramps because it would require some contortions to identify links between related people. On top of that it can only run in client/server mode.

Any ORM like SQLAlchemy, SQLObject, or the Django ORM are implemented on top of DB-API and I recommend using any of these over direct DB-API because it can give Gramps the flexibility to run sqlite in embedded mode for local desktop users and then also share, sometime down the road, a Postgresql/MySQL database connection with a web based version of Gramps.

Answer 3

web2py has a database abstraction layer that can be used in a standalone manner. We switched between sqlite3, Microsoft SQL Server, Oracle and MySQL with zero code changes. Impressed.

Answer 4

When I started converting a legacy app to use an ORM I looked into SQLObject and SQLAlchemy. At first I went with SQLObject because it looked familiar (past Django experience) and SQLAlchemy seemed complicated. After about 2 hours I started to hit walls with SQLObject. I then looked at SQLAlchemy again and was instantly rewarded. Not only did it understand and map every weird table in the database, it even could do the even weirder lookups I had to do later!

Answer 5

I think that CouchDB would be best choice for such project as Gramps.

Useful CouchDB features for Gramps:

• No schema, no migrations.

• Support for storing files directly to database, for example family photos, etc.: http://guide.couchdb.org/draft/api.html#attachments

• Ubuntu supports CouchDB via desktop-couch and it is integrated with Ubuntu One for easy sharing or backuping: http://www.freedesktop.org/wiki/Specifications/desktopcouch

• You can easily replicate couchdb databases, join them to one big database, etc...

• couchDB is very flexible.

Answer 6

Accessing a proper database from Python is almost always done using a DB-API 2.0-compliant adapter module. While all DB-API modules have identical APIs (or very similar; not all backends support all features), if you are writing the SQL yourself, you will probably be writing SQL in a product-specific dialect, so they are not as interchangeable in practice as they are in theory.

Honestly, SQLite sounds perfect for your use case. I wouldn't bother with "embedded MySQL"; that sounds like the worst of both worlds. Whether you want an ORM like SQLAlchemy is completely up to you; there are good arguments either way. Personally, I dislike ORMs, but then I have a math degree, so the fact that I appreciate SQL as a language probably isn't too surprising :)