SQLAlchemy seems really heavyweight if all I use is MySQL.
Why are convincing reasons for/against the use of SQLAlchemy in an application that only uses MySQL.
SQLAlchemy seems really heavyweight if all I use is MySQL.
Why are convincing reasons for/against the use of SQLAlchemy in an application that only uses MySQL.
ORM means that your OO application actually makes sense when interpreted as the interaction of objects.
No ORM means that you must wallow in the impedance mismatch between SQL and Objects. Working without an ORM means lots of redundant code to map between SQL query result sets, individual SQL statements and objects.
SQLAchemy partitions your application cleanly into objects that interact and a persistence mechanism that (today) happens to be a relational database.
With SQLAlchemy you stand a fighting chance of separating the core model and processing from the odd limitations and quirks of a SQL RDBMS.
I don't think performance should be much of a factor in your choice. The layer that an ORM adds will be insignificant compared to the speed of the database. Databases always end up being a bottleneck.
Using an ORM may allow you to develop faster with less bugs. You can still access the DB directly if you have a query that doesn't work well with the ORM layer.
sqlalchemy provides more than just an orm, you can select/insert/update/delete from table objects, join them etc.... the benefit of using those things over building strings with sql in them is guarding against sql injection attacks for one. You also get some decent connection management that you don't have to write yourself.
The orm part may not be appropriate for your application, but rolling your own sql handling and connection handling would be really really stupid in my opinion.