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

61–70 of 354 posts

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

#61

Post by zadikian »

hatefulheart wrote: post #26
stephen wrote: post #15

I'm admittedly an ORM apologist [1], but a few of his points articulated as "deal breakers" aren't that bad imo: - "the pernicious use of foreign keys [...] links between classes are [...] foreign keys" ==> that just sounds like schema normalization, which is usually a good thing? - "bending over backwards [...] to generate SQL that runs efficiently" ==> the huge majority of ORM-driven queries are "select * from tabl…

I have seen many ORM enjoyers argue the point about “you can just use SQL!” but I have never once seen an ORM enjoyer allow it, much less do it themselves in an actual codebase. They will time and time again prefer you write 100 lines of Typescript/Python for what could be achieved with 15 lines of SQL.

And then the 100 lines of JS/Py ends up being way slower than the manual SQL, plus the autogen'd SQL part of it is slow, plus you can't even get the SQL query to profile without running the actual thing with prints.

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

#62

Post by zsoltkacsandi »

ChicagoDave wrote: post #41

ORMs taught me that relational databases are an operational anti-pattern. NoSQL for operational data storage is more efficient and cost effective. ORMs were a regression test that exposed unnecessary complexity.

I’ve never seen any reliable service built on a NoSQL store as a primary data store. If data consistency and not losing customer data important for you, RDBMS are just fine.

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

#63

Post by airstrike »

hatefulheart wrote: post #40
nfw2 wrote: post #36

Earlier quoted context omitted.

The reason given to use raw SQL is for the performance not the perceived code clarity.

I’m not sure why you thought I meant code clarity and not performance? It’s clear in all cases the correct SQL query will be more performant. Confused at what you’re evening trying to say here. Are you suggesting that 100 lines of application layer code is easier to understand than 15 lines of SQL?

The correct SQL query will be more performant than what? The correct ORM call will build the same correct SQL query.

ORM is ultimately SQL

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

#64

Post by airstrike »

marcosdumay wrote: post #52
stephen wrote: post #28

Earlier quoted context omitted.

You're right, that has been another "pro ORM" pitch that has gone awry and, taken to the extreme, is wrong imo. My nuanced articulation is "you don't have to write the _boilerplate_ SQL for the 90% of just-do-some-CRUD endpoints in your enterprise SaaS application, but you 100% need to 'know SQL' for the last 5-10% of ~reporting/analytics queries that the ORM is going to mess up".

AKA making the easy parts easier while making the difficult parts harder.

The difficult parts are just literally a raw SQL string so how is that any harder?

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

#65

Post by bearjaws »

stephen wrote: post #15

I'm admittedly an ORM apologist [1], but a few of his points articulated as "deal breakers" aren't that bad imo: - "the pernicious use of foreign keys [...] links between classes are [...] foreign keys" ==> that just sounds like schema normalization, which is usually a good thing? - "bending over backwards [...] to generate SQL that runs efficiently" ==> the huge majority of ORM-driven queries are "select * from tabl…

> the huge majority of ORM-driven queries are "select * from table where id in ..."; for the queries that are more complicated than that, then yes use SQL! That's allowed!

The issue is, your lowest value queries are always this type, then you get the 10-20 in any code base that are 100x more complex, and they are the ones your end users care about the most.

You end up with a 80/20 principal in the wrong way, it's great at producing queries that represent 20% of the value of your app, and awful for the 80% that define the core value of it.

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

#66

Post by hparadiz »

hatefulheart wrote: post #35
hparadiz wrote: post #27

Earlier quoted context omitted.

I've written/worked on several ORMs from scratch. ORMs are the industry standard. When I see posts like this I simply can't take them seriously. All they are saying is "I won't be a team player" and "I don't actually understand the subject matter". The reality is at a certain scale there's an entire orm team that optimizes everything. But even when there's no team involved there's no way you can write anything more o…

What optimizations are you making here when at the end of the day performance is dictated by the schema, the query planner and the network?

How can I possibly condense 24 years of deep knowledge in one comment for you?

The tldr is if you're ever concatenating strings in order to build a query you're just doing what the entire job of orm is but rolling your own and chances are you'll end up with a bunch of bugs in how you handle well.... Everything.

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

#67

Post by [deleted] »

stephen wrote: post #15

I'm admittedly an ORM apologist [1], but a few of his points articulated as "deal breakers" aren't that bad imo: - "the pernicious use of foreign keys [...] links between classes are [...] foreign keys" ==> that just sounds like schema normalization, which is usually a good thing? - "bending over backwards [...] to generate SQL that runs efficiently" ==> the huge majority of ORM-driven queries are "select * from tabl…

[deleted]

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

#68

Post by hatefulheart »

hparadiz wrote: post #66
hatefulheart wrote: post #35

Earlier quoted context omitted.

What optimizations are you making here when at the end of the day performance is dictated by the schema, the query planner and the network?

How can I possibly condense 24 years of deep knowledge in one comment for you? The tldr is if you're ever concatenating strings in order to build a query you're just doing what the entire job of orm is but rolling your own and chances are you'll end up with a bunch of bugs in how you handle well.... Everything.

I think your tone is a bit combative. You can certainly provide the cliff notes but if you want me to believe you’re at working at computational limits whilst talking to me about string concatenation in web dev backend languages I think the burden of proof is on you.

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

#69

Post by airstrike »

mrweasel wrote: post #32
flir wrote: post #6

Earlier quoted context omitted.

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.

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 language…

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

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

#70

Post by [deleted] »

revetkn wrote: post #59

If you use Java and like to write SQL, check out https://pyranid.com I stopped using ORMs around 2008 because they made the easy problems easier and the hard problems harder. I wanted to just write SQL and exploit all the power the DBMS has to offer instead of fighting with an abstraction layer, so I created Pyranid in 2015 and keep it actively updated.

[deleted]
Post reply on HN