Now that I’m building a serious db-backed site with Python, I have a better appreciation for what database mapping packages are like. I’m using Django (pre-magic-removal for the moment), and am already bumping up against the limitations of the object relational mapper (ORM).
So I was impressed to see SQLAlchemy’s philosophy statement:
SQL databases behave less and less like object collections the more size and performance start to matter; object collections behave less and less like tables and rows the more abstraction starts to matter. SQLAlchemy aims to accommodate both of these principles.
SQLAlchemy doesn’t view databases as just collections of tables; it sees them as relational algebra engines. Its object relational mapper enables classes to be mapped against the database in more than one way. SQL constructs don’t just select from just tables—you can also select from joins, subqueries, and unions. Thus database relationships and domain object models can be cleanly decoupled from the beginning, allowing both sides to develop to their full potential.
We’re not moving away from the Django ORM (this week), but it’s good to have an understanding of the options out there, and SQLAlchemy looks quite promising.