Hacker News new | ask | show | jobs
by aussieguy1234 870 days ago
For those people who would rather use an ORM, its worth mentioning that ORMs write very bad, un-performant SQL under the hood.

They may save you a bit of time initially but when your company gets bigger, the ORMs will become a bottleneck.
2 comments
abhibeckert 870 days ago
"Bad" and "un-performant" are relative terms and as your company gets bigger, you're increasingly more and more likely to have colleagues who write even worse queries than an ORM would.

For example I've encountered queries that are not only slow, but they generate several hundred megabytes of output all of which is sent to the user's web browser where JavaScript selects the relevant two kilobytes of data to show the user.

The worst I've ever seen was a system where every single write to the database would be sent to every single web browser viewing certain webpages. 99.999999% of the writes were completely irrelevant and javascript in the browser would simply disregard them. The server load was immense... and eventually our Sysadmin brought it to someone's attention. Where we found out it was leaking sensitive data.

link
aussieguy1234 870 days ago
I guess once you get to a certain point, you need to hire engineers that have strong SQL skills in order to scale.
link
klibertp 870 days ago
> They may save you a bit of time initially but when your company gets bigger, the ORMs will become a bottleneck.

At which point - but not earlier! - you just make your ORM print the queries, fix them manually (or write them from scratch). You then can ditch the ORM, use it as a query builder DSL only, or use escape hatches provided by the ORM to inject raw SQL.

Don't use ORMs as a crutch to get away with not knowing SQL, that's bad. However, saving "a bit" - and with good ORMs, that "bit" is quite large - of time in the beginning is often very valuable. Just have a clear "exit strategy" for when (and in 90% of projects, if) it's needed.

link