Surprised to see no one has mentioned query builders (like http://knexjs.org - no affiliation). All the niceties of not writing raw queries but no abstraction leaks... Although I have found for anything more interesting (recursive queries, etc) there is no escaping raw queries and every developer needs to bite the bullet and learn SQL.
What ORMs have taught me: just learn SQL (2014)
71–80 of 654 posts
Re: What ORMs have taught me: just learn SQL (2014)
#72Thread 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
And another very recent discussion which treads on similar ground:
Re: What ORMs have taught me: just learn SQL (2014)
#73ORMs 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…
> They are for making manipulating the entities
This is where I disagree. I dislike having a value which is the entity. The basic lesson from relational databases and later data oriented design is that you don't have an entity. All you have are aspects that are related.
Re: What ORMs have taught me: just learn SQL (2014)
#74I’ve come to the same conclusion even working with ActiveRecord. SQL is very literally a domain-specific language for working with relational data; why would we go so far out of our way to eschew writing code in it?
> SQL is very literally a domain-specific language for working with relational data; why would we go so far out of our way to eschew writing code in it?
It is, and all ORMs I know use it under-the-hood. It is the boilerplate code by which SQL is issued to the DB, and results parsed into something usable by the rest of the program that people try to avoid writing over and over.
Re: What ORMs have taught me: just learn SQL (2014)
#75We 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 trivially, sometimes not.
The other thing that comes to mind here is that maybe the query was hitting a non-covering index and that was triggering the lookups? In that case a covering index would have fixed the issue?
Curious about this one...
Re: What ORMs have taught me: just learn SQL (2014)
#76[deleted]
Re: What ORMs have taught me: just learn SQL (2014)
#77ORMs 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…
There's absolutely nothing in this world that has frustrated me more than knowing how to write a query in SQL but, for the life of me, not being able to express it using the ORM syntax.
Since then I keep using ORMs (because mapping the things you pull from the db to actual objects is undoubtedly good) but I write my queries by hand.
I also dislike ORMs that, by default, when you try to access an object you forgot to pull from the db with the query you wrote, automatically generate another query to pull the data instead of erroring out.
Re: What ORMs have taught me: just learn SQL (2014)
#78I mostly agree. But lately I've been using Ecto, and I like the approach. It's mostly an SQL generator. So far it's the sanest approach to ORM I've used.
Re: What ORMs have taught me: just learn SQL (2014)
#79Each 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…
To me it is more of as Ted Neward describes "ORM is Vietnam of Computer Science"[1]
"Although it may seem trite to say it, Object/Relational Mapping is the Vietnam of Computer Science. It represents a quagmire which starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy."
[1] http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...
Re: What ORMs have taught me: just learn SQL (2014)
#80We 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…
Wait, this is displayed gray. It got downvoted???
Maybe it's because the problem isn't directly caused by ORMs but just a very poor usage of ORMs. The same problem would have existed if a loop was written to perform the same query.