In case this article is at risk of convincing someone to use an ORM: Just don't, please. Do not use an ORM. Write your own SQL.
I was once a huge advocate of ORMs, and built one many years ago, for Java, (it solved the N+1 problem). It was getting some use, and working as advertised.
One day, I had a discussion with a prospect who decided not to use it. It was a lot more important to her to have x years of Oracle on her resume, than x years of <obscure ORM> on her resume. That really stuck with me. And then the brittleness of ORMs in general became apparent: Things get difficult when the schema or model changes. "select *" is terrible, in general. And if you modify your model to omit some columns, then those columns are always omitted. Stored procedures don't fit very well, (updates risk leaving cached objects stale).
But I think the biggest problem is this: When using a database system properly, you want to control the SQL being issued. This is especially true for expensive queries, but not only in that case. And with an ORM, you are concerned not just with getting the SQL right, but with expressing yourself via the ORM. You need to get the ORM to issue the correct SQL, which defeats the whole point of an ORM in the first place.
An ORM isn't a free pass, excusing you from understanding your database system. If you don't understand SQL, and relational databases, and the quirks of the particular database system you are using, then you are likely to screw things up.
Learn about relational databases and SQL. And then adding SQL to your application just isn't that big a deal.
Hmmm, it seems I repeatedly have this discussion with others re: ORMs are inferior. If there is one point I initially wanted the article to make is to use relational databases first, and ORMs second. (i.e: as opposed to NoSQL solutions.) Perhaps I should edit the intro to the article to reflect that.
I was once a huge advocate of ORMs, and built one many years ago, for Java, (it solved the N+1 problem). It was getting some use, and working as advertised.
One day, I had a discussion with a prospect who decided not to use it. It was a lot more important to her to have x years of Oracle on her resume, than x years of <obscure ORM> on her resume. That really stuck with me. And then the brittleness of ORMs in general became apparent: Things get difficult when the schema or model changes. "select *" is terrible, in general. And if you modify your model to omit some columns, then those columns are always omitted. Stored procedures don't fit very well, (updates risk leaving cached objects stale).
But I think the biggest problem is this: When using a database system properly, you want to control the SQL being issued. This is especially true for expensive queries, but not only in that case. And with an ORM, you are concerned not just with getting the SQL right, but with expressing yourself via the ORM. You need to get the ORM to issue the correct SQL, which defeats the whole point of an ORM in the first place.
An ORM isn't a free pass, excusing you from understanding your database system. If you don't understand SQL, and relational databases, and the quirks of the particular database system you are using, then you are likely to screw things up.
Learn about relational databases and SQL. And then adding SQL to your application just isn't that big a deal.