4 ms·

I wholeheartedly agree with the article. Every time I've used an ORM I've regretted it. SQL is already a great DSL for working with relational data, and there i

I wholeheartedly agree with the article. Every time I've used an ORM I've regretted it. SQL is already a great DSL for working with relational data, and there is no reason to create a leaky abstraction on top of it. The reality is that there is no practical way to do efficient mapping from relational data to object models, and pretty much every ORM ends up generating horridly inefficient queries when you start getting into non-trivial cases. At that point you're going to have to go in and write the queries by hand anyways. So, you might as well just skip that step and work directly with SQL. The worst part is that you often find out that ORM is affecting performance when you start hitting real world loads in production.

mumblemumble 7y ago
It doesn't always affect performance. A lot of business apps are mostly doing CRUD under fairly light load. It may be that beefing up the database server is much cheaper than interacting with the database in a way that, while being more performant, is also more laborious. That said. . . yeah, I've also had my share of cases where the app ended up seeing higher load than anyone anticipated, and it's hard to even see the source of the performance problem, because, with an ORM, it takes a little bit (or, with the worse ones, a lot) more work to find out what the actual queries being executed are so that you can ask the DBMS to `EXPLAIN` its query plans.
- yogthos 7y ago
  Except, I don't find using SQL more laborious, and it if is then I'd suggest that's a problem with whatever language makes using SQL directly laborious.