Comment by digiwano | Hacker News Reader

Comment by digiwano | Hacker News Reader

Parent Full thread

I’m not saying developer-friendly APIs are bad, but i do think hand-crafted, well-written, and well-tested SQL outperforms any ORM, and if any ORM comes close to the performance of hand-crafted queries, it does so at the cost of complexity.

Raw database queries aren’t difficult except in extreme edge cases that most ORMs aren’t smart enough to handle either. ORMs do make things slightly “easier”, but that comes at a cost. Whether that cost is in terms of performance or complexity or developers losing understanding/knowledge of how to build code that leans into the benefits of whichever database you choose comes down to whichever ORM you’re using, but that trade off will always be there.

And either way, 99% of people using any random ORM have no idea whether a `select *` is being used or not. That’s the whole point. You put blind faith into whatever ORM believing it will do the “right”/“most optimized” thing.

On top of that you only have to learn SQL once and you can use it pretty much everywhere without having to learn a different ORM - Learn once, write everywhere.

Another thing that speaks for raw SQL is that it's a lot easier to debug queries, just copy/paste the query into your SQL editor and start figuring out what's wrong, you can't just do that with an ORM.

"debug queries"

yea, that's the point where things start getting exciting when you have logic in queries that you actually have to debug.

I too love 200 LoC (tiny, in fact) procedures that inside build ""dynamic SQL"" aka string concat and EXEC with many OUTPUT parameters

10/10 experience, would recommend it to everyone.

No, I don't want to debug my queries because it means that I'm probably doing too much on the database.

I treat database more like a fancy data storage with outdated language, not as a business logic layer.

There's a cost to everything, including enumerating just the fields you need from the query. When a new column is added, does a developer now need to revisit every query involving that table, update if necessary, and retest? That has a very real cost in terms of time and money, probably more than the cost of 'SELECT *', or not using an ORM.

A lot of times, the technically 'optimal' solution isn't necessarily optimal.

Add it only in the queries that require that column. Knowing where you need a new column should make adding a field easy.

Reply on news.ycombinator.com