SQLAlchemy: Continuing to Learn

Ok – my work with SQLAlchemy is continuing. So far, the experience has been one of advantages and disadvantages.

The Advantages/The Plus Side:

• My framework can use several different database engines without my having to change my code. I simply change a connection string.
• I have a way of thinking that is peculiar to me, and this experience with SQLAlchemy is helping me to understand how others think. I frequently need to work with code that was written by others, and SQLAlchemy represents an approach that is not going to go away. I might as well learn about it. (The last project I worked on used a framework that had many of the same features as SQLAlchemy.)

The Disadvantages:

• If I had developed my code using the approach I am used to using, I would be done now. (Of course, I would also have tied myself to a specific database product.)
• I am having to flip through manuals to write the simplest snippets of code. I already know how to write the SQL, and I already know how to write stored procedures to do what I want to do. I am frustrated at times, but I will keep with it.
• I can already see places where performance degrades because of SQLALchemy. I pride myself on databases that perform very well – and I like to tune databases.

But, in the end, having the freedom to use different database engines means a lot to me. I like the fact that I have postponed the decision of commiting to an underlying database. I cannot say that I regret using SQLAlchemy. I may want to share my code at some point, and I prefer to let users of the code choose whatever relational database they like.

On the other hand, I like using special features of a database – SQLAlchemy ties my hands a little.

Many people develop a database along with an application. This means that the database and the application are of a piece. I often think of the database as separate – it may be used by multiple applications, and it should be designed with this in mind.
In any event, the work continues.