I don't particularly disagree with anything in that post, but the fact is that the code time saved with an ORM is so massive, that NOT using one is effectively gross premature optimization.
Sure, as your app grows, you write SQL to speed up the bottlenecks. And that's O.K.
It depends on the ORM you use, but I'm afraid it's not as simple as "you can later hand write SQL queries to speed things up". This will interact badly with the ORM's cache/transaction handling: your select queries won't see uncommitted changes held by the ORM, and even worse, your ORM won't see the modifications you made with insert/update/delete SQL queries.
Also, one of the pro ORM arguments is that it generates database-specific SQL, making your code theoretically portable between different RDBMS. Hand writing SQL will break this.
Another point: your ORM would automatically pick up changes to your model and cope with it, not your hand-written SQL, making your code harder to maintain.
>> ... one of the pro ORM arguments is that it generates database-specific SQL ... portable between different RDBMS
Yes, hand writing SQL will break this but:
- it is rare in my experience to completely migrate to a different RDBMS
- migrating to a different RDBMS should easily be viewed by everyone from management to development as a very tricky process that will take time to perform correctly. Part of this time will be tuning your custom queries.
- the ORM promise that it's queries are RDBMS independent is not broken
>> Another point: your ORM would automatically pick up changes to your model and cope with it, not your hand-written SQL, making your code harder to maintain.
Writing everything by hand (known alternative 1 from the article) makes your code even harder to maintain because there will be zero changes that are automatically picked up.
Depending on the KV store you use, his second alternative may not have this problem.
TLDR:
Hand writing sql comes with a cost, but the overal cost of "ORM + a bit of handwritten sql" is likely to be much less than "everything handwritten".
In general, people don't migrate between databases. In specific, I find myself migrating from sqlite to either Mysql or Postgres relatively frequently.
That depends on what kind of products you make: If it's a website, then you have absolute control over what stack and database to use. But if you're selling any kind of app that needs a database, then you'll need to support different databases. Some customers won't ask questions and take your default database, others (unfortunately ?) will want it to use their Oracle/SQLServer installation that cost them a bazillion.
These are limitations of specific ORMs or ORM classes, not of the concept in general.
> Another point: your ORM would automatically pick up changes to your model and cope with it, not your hand-written SQL, making your code harder to maintain.
You mean, I'd need to re-write LESS hand-written SQL with model changes. This is a selling point, not a down side.
Sure, as your app grows, you write SQL to speed up the bottlenecks. And that's O.K.