Is it true that ORM allows for changing the type of SQL that you use easily?

Question

Hey so I have been looking into ORM since my last question and I am wondering.

Instead of worrying alot right now about whether I will use mysql, postgre, or sqlite, would it be better to use ORM along with flask and SQLAlchemy and thus be able to change the databases more easily? Or did I get ORM wrong when reading about it...

Answer 1

Being able to change the actual database is not an intrinsic property of ORM, but many (most?) ORM libraries do provide that ability.

The main goal of an ORM is to bridge the gap between the RDBM world of tables, keys and queries and the OO world of objects, inheritance and associations/aggregations/compositions. They are intended to make your life easier when accessing a database from an OO context and/or mindset.

Answer 2

Yes and no.

While a lot of ORMs offer this functionality and it usually works just fine when you actually have real production data you will most likely realize that this is just small part of the problem.

Ive been part of several projects for switching an app from database X to database Y during my career and even those projects that used an ORM was...painful. The main reason for this is that if you have spent time writing code for one database (say MSSQL) then even if you use an ORM you will end up structuring your data for what is fast and works good in that database. And when you later switch to something else, lets say PostgreSql, you will notice that...the same thing that is quick in MSSQL might be slow postgres, and vice versa.

The ORM cant help you with this. At some level, the ORM will probably even work against you when you try to solve this issue (since the ORM is a layer on top the SQL you will have a harder time actually finding the slow queries, figuring out whats wrong with them and optimizing them).

In my experience, the ORM helps you with the part that was already "easy" with a database switch. But for the part that is actually hard...you are on your own, and the ORM might even work against you.

With that said, consider your use case. How much data will you have? Why are you switching databases? What is your performance targets? For some apps, the things Im talking about it not something that you even need to consider in the first place.