Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What ORMs have taught me: just learn SQL (2014)

wozniak.ca

Post reply on HN
Print view View original

41–50 of 654 posts

Re: What ORMs have taught me: just learn SQL (2014)

#41

Post by wvenable »

daenz wrote: post #32
wvenable wrote: post #30

Earlier quoted context omitted.

You don't use ORMs for gnarly queries -- that's not what they are for! They are for making manipulating the entities easier -- reading the data out of the database in a way that makes easy to modify. You can (and should) use them for simple queries. You have a list of entities you want to query and filter, that's going to be fine. Joins are fine. But if you're doing some complex analysis, an ORM is the wrong tool. Th…

If the argument is that it's the right tool for simple jobs, then by definition it won't save a lot of effort.

That's not true. A simple job might be 3 lines of code in an ORM to update a record. In SQL that will be a lot more code especially if that's wiring up a foreign relationships. With SQL you will also have a lot of uncheckable strings containing code.

Simple tasks are done maybe thousands of times in any one application. It's the complex tasks are rare.

Re: What ORMs have taught me: just learn SQL (2014)

#42

Post by Roboprog »

dang wrote: post #11

Thread from 2017: https://news.ycombinator.com/item?id=15949144 2016: https://news.ycombinator.com/item?id=11981045 Discussed at the time: https://news.ycombinator.com/item?id=8133835

I know, this is a recurring discussion.

Both sides continue to distrust the other, though.

Re: What ORMs have taught me: just learn SQL (2014)

#43

Post by commandlinefan »

psetq wrote: post #19

These things don't have to be mutually exclusive. Know your tools and when to use them.

In my experience, though, the cases where ORM's seem to be a good fit end up growing to cases where they're no longer a good fit - and getting away from them ends up hurting more than just starting without one to begin with.

Re: What ORMs have taught me: just learn SQL (2014)

#44

Post by geophile »

wvenable wrote: post #30
daenz wrote: post #14

ORMs lure you in with a false sense of neat abstraction. They have nice intuitive examples on their home pages. But then you use them in the real world, doing gnarly queries, and you realize that doing anything powerful and fast in the ORM requires its own completely separate abstractions, which are often difficult for the uninitiated to follow. It's also often a big pain to debug the raw SQL that gets compiled after…

You don't use ORMs for gnarly queries -- that's not what they are for! They are for making manipulating the entities easier -- reading the data out of the database in a way that makes easy to modify. You can (and should) use them for simple queries. You have a list of entities you want to query and filter, that's going to be fine. Joins are fine. But if you're doing some complex analysis, an ORM is the wrong tool. Th…

ORMs make the simple things simple, and the complicated things impossible.

Re: What ORMs have taught me: just learn SQL (2014)

#45

Post by mikeryan »

trjordan wrote: post #10

Code thinks in objects and functions and values and pointers. Databases think in tables and columns and rows and queries and indexes. If you don't pick an ORM to help manage this translation layer, then you'll end up re-implementing your own. Maybe this is OK, because yours will be simpler for quite some time. What else are you going to do? Stored procedures? Concatenated strings?

I always feel that the arguments against ORMs is like the one against frameworks or using “Vanilla JS”. Saying you don’t use one really means you’re just writing your own.

Re: What ORMs have taught me: just learn SQL (2014)

#46

Post by kodt »

daenz wrote: post #32
wvenable wrote: post #30

Earlier quoted context omitted.

You don't use ORMs for gnarly queries -- that's not what they are for! They are for making manipulating the entities easier -- reading the data out of the database in a way that makes easy to modify. You can (and should) use them for simple queries. You have a list of entities you want to query and filter, that's going to be fine. Joins are fine. But if you're doing some complex analysis, an ORM is the wrong tool. Th…

If the argument is that it's the right tool for simple jobs, then by definition it won't save a lot of effort.

It might not save a lot of mental "effort" but they still save a lot of time that would otherwise be spent on writing simple boilerplate code.

Re: What ORMs have taught me: just learn SQL (2014)

#47

Post by _frkl »

daenz wrote: post #32
wvenable wrote: post #30

Earlier quoted context omitted.

You don't use ORMs for gnarly queries -- that's not what they are for! They are for making manipulating the entities easier -- reading the data out of the database in a way that makes easy to modify. You can (and should) use them for simple queries. You have a list of entities you want to query and filter, that's going to be fine. Joins are fine. But if you're doing some complex analysis, an ORM is the wrong tool. Th…

If the argument is that it's the right tool for simple jobs, then by definition it won't save a lot of effort.

I don't think that is what parent wanted to say. It's still a lot of boilerplate code and config that can be avoided by using an ORM for the 'simple' parts of an application. And if you use a framework like sqlalchemy, you still have access to the lower levels if it turns out the ORM abstraction is unsuitable.

Re: What ORMs have taught me: just learn SQL (2014)

#48

Post by Roboprog »

meesterdude wrote: post #13

> I do know one thing: I won’t fall into the “ORMs make it easy” trap. They are an acceptable way to represent a data definition, but a poor way to write queries and a bad way to store object state. If you’re using an RDBMS, bite the bullet and learn SQL. I don't think i'm alone in saying I'd rather hire a developer who is native with an ORM and can dive into SQL when things get thorny, than hire one who's going to f…

Alas, so true.

I tolerate an ORM at work. Secretly loathing it. Like much of industrial programming.

Re: What ORMs have taught me: just learn SQL (2014)

#49

Post by DoreenMichele »

Roboprog wrote: post #42
dang wrote: post #11

Thread from 2017: https://news.ycombinator.com/item?id=15949144 2016: https://news.ycombinator.com/item?id=11981045 Discussed at the time: https://news.ycombinator.com/item?id=8133835

I know, this is a recurring discussion. Both sides continue to distrust the other, though.

Listing prior discussions is not a reprimand suggesting we can't discuss it again. It's a service to the community to let us see what's already been said, if we so desire.

Re: What ORMs have taught me: just learn SQL (2014)

#50

Post by j88439h84 »

725686 wrote: post #37

Each time I see someone complain about ORMs I remember Greenspun's tenth rule[1], which adapted to ORM would be: "Any sufficiently complicated program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a decent ORM." ORMs are hard for a reason. Using an ORM doesn't mean you can't or shouldn't use plain SQL where the situation calls for it. You can mix and match perfectly fine. [1] ht…

Very good point. I'll need to remember this.
Post reply on HN