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

91–100 of 654 posts

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

#91

Post by geodel »

geophile wrote: post #44
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…

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

Now this is excellent point which is true in my experience. It gives little ramp up in starting and keep creating speed breakers as development proceeds to handle real complex business scenarios.

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

#92

Post by time0ut »

I've found that you need to first understand basic SQL very well. Then once you've mastered the ORM, it can dramatically improve your productivity. But you need to understand both to reason about what you are doing.

ORMs have their place. Simple CRUD microservice? An ORM can help tremendously. Complex reporting system? Probably not the right tool.

Be careful though. I've run into issues where once you're scaled way up and need the ORM to get out of the way, it can be a beast to detangle if you weren't disciplined.

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

#95

Post by elamje »

What are some good rule-of-thumbs for when to use ORM vs SQL?

I have worked with SQLAlchemy and Entity Framework, before and like them, but haven’t been able to find that magical demarcation line for when to go raw SQL.

Does anyone have basic rules they use for determining this? Applicable to MVP or enterprise level products

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

#96

Post by dsego »

wolco wrote: post #62

Active record is a great pattern. Where things fall apart is when you want to do things like a subquery on a select field.

Like this? https://laravel.com/docs/6.x/eloquent#advanced-subqueries

Seems more like a limitation of particular implementation than a fundamental problem with the pattern.

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

#97

Post by bob1029 »

hdfbdtbcdg wrote: post #59
bob1029 wrote: post #51

Swapping from EF6 to Dapper was one of the best choices we ever made with our project stack. It is so relieving to be able to hand-tune queries and transactions now. Initially, we were sold on the apparent simplicity of EF6, but as with many things there is a cost for an abstraction like this. In our case, the performance penalties and opaqueness were dealbreakers after a while. We saw an average speedup of 10x on al…

I am seriously glad I don't work on this project!

Care to elaborate on which aspect noted above is adverse from your perspective? I would be happy to provide more context and explain in more detail some of the reasoning involved in our decisions.

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

#98

Post by runin2k1 »

james_s_tayler wrote: post #75
JimmyRuska wrote: post #16

We used a third party tool for mailers and it was having severe performance problems after moving the server to a cloud based solution. We confirmed what the DBAs said, the latency was only 34 seconds round trip and the database was pretty fast. I installed wireshark to see what was going on. It was querying a table with 80,000 entries, and then for each entry it would do another, "select ... limit 1" query to get th…

This doesn't fully make sense to me... I'm kind of curious about what data the select limit 1 queries were returning that the ORM couldn't get in a single query and had to go back per record. Can you shed any light on this? ORMs have a degree of flexibility. It's possible to write n+1 queries accidentally, especially for developers who are new to the ORM. It's also often possible to address those issues. Sometimes tr…

It is almost certainly someone using lazy-loading when they should have disabled it for that query.

Though... since it sounds like the query was returning the entire table at once eager loading will cause issues of another variety at some point.

Either way, I'd chalk it up to bad design rather than bad tools.

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

#99

Post by yawaramin »

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…

> ORMs are hard for a reason.

Yes, the object-relational impedance mismatch. It's the classic case of having a hammer (OOP) and trying to make everything look like a nail.

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

#100

Post by Rapzid »

peterhadlaw wrote: post #39
daenz wrote: post #32

Earlier quoted context omitted.

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

Just because a job is simple doesn't mean it doesn't take time & effort. A tool can be helpful if it reduces the time or effort to accomplish something.

> Just because a job is simple doesn't mean it doesn't take time & effort

See digging.

Post reply on HN