Top
Best
New

Posted by ciconia 3 days ago

What ORMs have taught me: just learn SQL (2014)(wozniak.ca)
118 points | 161 commentspage 4
Kaliboy 6 hours ago|
I feel like ActiveRecord has none of these problems, but I also feel some strong confirmation bias.

Can anyone that has used ActiveRecord share their opinion?

dzonga 3 hours ago|
ActiveRecord does have the problem of excess joins though.
capitainenemo 5 hours ago||
I thought this was well put. https://web.archive.org/web/20160301022121/http://www.revisi...

A now defunct site discussing why ORM is a poor map.

armdave 3 hours ago||
> Most of that has been with SQLAlchemy (which I quite like) and Hibernate (which I don’t)

Can the OP expand on why this is? Just curious.

zadikian 5 hours ago||
I never use ORMs. But slightly before 2014, there was still kind of a reason to use them, getting/setting a whole nested bag of fields at once that you don't care about individually. Json/jsonb now handles that better.
Waterluvian 6 hours ago||
What Python taught me: just use C.

These are simply tools. The only wrong opinion is to believe that there’s a strict superiority of one over another. However, the content of this and other blogs can help people make informed decisions on when to reach for each tool.

nomilk 5 hours ago||
> August 3, 2014

That's important. Because now days it's trivial for LLMs to translate ORM to SQL and vice-versa with ~100% accuracy. I haven't written any raw SQL (only Active Record) in about two years, and the odd time I blunder with AR and create an n+1 I find out about it via error tracking (e.g. Sentry) a few minutes later and fix it. No biggie.

There's also an additional layer of protection in that using AI on the codebase can spot SQL blunders incidentally (i.e. you ask about X, and the AI does X but also says "Not asked, but flagging for your attention: problem with SQL on line 256 etc.."

r2ob 4 hours ago||
ORM is a great tool for data input. Complex output I always write the old and good raw SQL query.
add-sub-mul-div 6 hours ago||
2014: people respond with indignance that they should have to learn SQL now that there's a shortcut

2026: people respond with indignance that they should have to learn anything now that there's a shortcut

flir 6 hours ago||
I like SQL. I enjoy writing SQL. I find ORMs produce crap SQL.

But the current shortcut du jour is pretty damn good at writing SQL.

mrweasel 6 hours ago|||
While I do enjoy the Django ORM, for many queries SQL is just better. It's almost as if it was designed for querying database.

Once you hit a certain level of complexity in your queries, you're better of with SQL. It's not that you can't do the query in the ORMs, but you're then looking at learning their special query language and those are never better nor easier to understand than just SQL. Those ORM query languages certainly aren't transferable across ORMs, but SQL frequently is. If you can query MariaDB with SQL, you can query SQLServer and PostgreSQL. The same can't be said for e.g. Django vs. Hibernate.

For the "give me all the entries, with this one property" ORMs a much quicker and easier to work with. Once you start needing to use subselect, multiple joins, weird ranges or constructing object with data from across tables, I'd rather just write the SQL myself.

airstrike 5 hours ago||
And Django makes it ridiculously easy to write those raw queries in SQL directly so it seems like you're getting lots of mileage from the ORM without giving up anything
3eb7988a1663 5 hours ago||||
I write SQL every day, but I cannot get onboard with liking the language. Yes, it is incredible that the language has had such staying power. No, it is not great that such a flawed design has persisted.

I enjoy this article[0] about some of the persistent warts which will seemingly never change.

[0]https://www.geldata.com/blog/we-can-do-better-than-sql

el_io 6 hours ago||
At yet people (mostly) skip SQL and learn some ORM.
bob1029 6 hours ago||
ORMs are a horrible fit for OLAP scenarios. I've got a situation where I need to load ~40 tables with a total of 100k+ rows and I need it to happen at user-interactive speeds (less than 10 seconds).

There is nothing that an ORM can do to help with this sort of problem without reaching for the obvious escape hatch of arbitrary command text execution. The ability to map the tables to objects in my programming environment is a distracting clown show for this specific problem. What really matters is understanding the provider and its techniques for bulk loading records. No ORM will ever be able to touch these provider capabilities on their "happy" paths. At best you'll wind up using the ORM and a bunch of provider-specific SQL anyways.

ORMs for schema management is a stronger argument, but only in cases where the codebase/service has complete ownership over each respective database. Any kind of heterogenous workload says that ORM for schema management is a potential nightmare unless you do something like create a project that is only for migrating the schema, at which point I'd argue you could just maintain a source controlled folder of sql/shell scripts.

andrewstuart 5 hours ago|
SQL is awesome and you’ll never get the best out of your database unless you learn to program the damn thing and bit hide behind some abstraction.

We do programmers always need a library?

Program the damn thing.

More comments...