I am beginning to get involved with a wide open source project Gramps that is exploring switching their after sales from BSDDB to some relational database. Either SQLite or MySQL we've not fully made the decision and might attempt to do in some limited capacity. I am a professional developer but I am a new comer to python so I am not too acquainted with the present choice of tools/libraries. I have been assigned with researching DB Abstraction Layers. There is presently a wiki discussion going onto do a comparison. An item relational mapper may be nice but is not essential. though I understand that's usually symbolic of a DB Abstraction Layer. If the ORM is incorporated ad hock queries need to be available without to much wrestling.
At this time their email list includes:
CouchDB I've not yet investigated this.
DB-API this appears to become a standard python api and every db produces their very own module that utilizes it. Even BSDDB appears to possess one written however i haven't fully investigated it. would be the modules interchangeable?
SQLAlchemy This appears to become typically the most popular at this time? however i have limited contact with the python world.
SQLObject I've not yet investigated this.
What exactly are peoples sights and suggestions on database abstraction layers for python?
Look very carefully at SQLAlchemy.
You can look at and develop with SQLite.
You are able to get into production with MySQL -- making basically no changes for your programs.
The DB-API, while broadly stuck-to, has enough versatility that (1) you are not insulated from SQL variation within the underlying RDBMS and (2) you will find still DB driver-specific features which are tough to hide.
One other good ORM layer may be the ORM that's a part of Django. You are able to (after some effort) use only the Django ORM without needing the relaxation from the Django web framework.
Make use of an ORM Layer (SQLAlchemy or SQLObject) instead of DB-API.
Why? Your model ought to be a good, obvious, well-thought-out OO model. The relational mapping should come second following the object model. SQLAlchemy makes mtss is a reasonable approach.
A "DB Abstraction Layer" may happen within the normal span of occasions. Indeed, due to DB-API (as utilized by SQLAlchemy) you gave two abstraction layers: ORM and DB-API.
Being able to access an effective database from Python is nearly always done utilizing a DB-API 2.-compliant adapter module. While all DB-API modules have identical APIs (or much the same not every backends support all features), if you're writing the SQL yourself, you'll most likely be writing SQL inside a product-specific dialect, so they aren't as interchangeable used because they are theoretically.
Honestly, SQLite sounds perfect to use situation. I wouldn't make use of "embedded MySQL" that seems like the worst of both mobile phone industry's. Whether you would like an ORM like SQLAlchemy is entirely up to you you will find good arguments in either case. Personally, I dislike ORMs, however I've got a math degree, so the truth that I appreciate SQL like a language most likely is not too surprising :)
CouchDB isn't a relational database, therefore it does not possess a DB-API interface. It is a document database meaning it can't be as helpful for Gramps since it would require some contortions to recognize links between related people. In addition it may only run in client/server mode.
Any ORM like SQLAlchemy, SQLObject, or even the Django ORM are implemented on the top of DB-API and that i recommend using these over direct DB-API since it can provide Gramps the versatility to operate sqlite in embedded way of local desktop customers after which also share, sometime in the future, a Postgresql/MySQL database reference to an internet based version of Gramps.