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

81–90 of 354 posts

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

#81

Post by 7bit »

hatefulheart wrote: post #68
hparadiz wrote: post #66

Earlier quoted context omitted.

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.

I don't think OP ever expected you to believe anything. He stated his experience and nothing more

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

#82

Post by hparadiz »

jghn wrote: post #71
hparadiz wrote: post #43

Earlier quoted context omitted.

This is inevitably what happens every single time so just use an ORM and stop being stubborn.

The problem is that "ORM" does a lot of heavy lifting as a term and can mean different things to different people. Like yes, obviously, one needs some sort of SQL -> data structure transition on the boundary (using "object" overfits to OOP!). But that can be extremely light weight. Let people write SQL, have a thin layer to pull the results back out into the appropriate data structures, and move on.

Every good ORM lets you write SQL. Mine for example has a getByQuery and getByWhere as standard methods. An ORM isn't just writing queries for you it's also handling type casting from lang primitives to SQL and back. In 99% of crud rest apis there should be no need to write your own SQL though.

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

#83

Post by ambicapter »

dadie wrote: post #18
valzam wrote: post #7

The big problem is that raw SQL has pretty bad type inference and linting support in most editors. A query builder can still give you a lot of type safety benefits.

I think the bigger problem is that SQL is in almost every language a second-class citizen. And even calling it second-class can be seen as a stretch.

I’m a SQL-lover and ORM-hater but I don’t see why any language would support another wholly different language as a first-class citizen.

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

#84

Post by maxwellg »

hn_throwaway_99 wrote: post #48
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…

> "bending over backwards [...] to generate SQL that runs efficiently" ==> 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! This is exactly why I hate ORMs. As I always put it "ORMs make the easy stuff slightly easier, and they make the harder stuff way harder". If you're just using an OEM for the…

> There are lighter weight options that do basic stuff like transaction management and binding result sets to object properties that are much less of a PITA than ORMs.

Query builders like these are my personal favorite from a productivity perspective! The point of a query builder is to dynamically build SQL statements that have many subtle variations (do we want to filter by EmailID or PhoneID here? What about a subquery? Did the caller want all results, or just results where $field=X?). They're basically one level above string templating for SQL generation, and often have niceties around ser/de and transaction management as you mentioned.

Because they are primarily about query generation, it feels _very_ natural to pop off the hood and write raw queries directly when necessary. You can usually use the transaction management and ser/de parts with raw queries, too.

My personal favorite in this field is knex.js.

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

#85

Post by Arch-TK »

pull_my_finger wrote: post #56

I wonder if the real problem isn't being able to write efficient queries, but that developers struggle to add (yet another) programming language. Just use AWK, just use SQL, just use jq, just use xyz. It's a lot of overhead. I would be OK to lose whatever fractional speed difference to be able to write my queries in a different scripting language. If I ever scaled so much that I needed to shave microseconds off my qu…

There are rather concrete problems that strictly prevent it from being possible to efficiently map graph (object) database access patterns to a relational database.

It's not a matter of "fractional speed difference" unless your database has very few entries. OR mismatch problems often like to appear shortly after your database starts to see any real use.

The only performant way to use an ORM is to use escape hatches everywhere. Alternatively, you can use an "ORM", something which calls itself an ORM while only doing superficial data mapping into dynamic or generated native (to your language) data structures. There are a _lot_ of these, most normal people call them query generators.

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

#87

Post by dagss »

ai_slop_hater wrote: post #10
valzam wrote: post #7

The big problem is that raw SQL has pretty bad type inference and linting support in most editors. A query builder can still give you a lot of type safety benefits.

[flagged]

I would argue that is a bit like complaining there is no "backend language" and that Java, Rust, Go all have different syntax.

The choice of DB is arguably more important than the choice of backend language.

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

#88

Post by hatefulheart »

7bit wrote: post #81
hatefulheart wrote: post #68

Earlier quoted context omitted.

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.

I don't think OP ever expected you to believe anything. He stated his experience and nothing more

Oh it was just a flex?

Ok then!

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

#89

Post by nomilk »

> 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.."

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

#90

Post by meindnoch »

dadie wrote: post #18
valzam wrote: post #7

The big problem is that raw SQL has pretty bad type inference and linting support in most editors. A query builder can still give you a lot of type safety benefits.

I think the bigger problem is that SQL is in almost every language a second-class citizen. And even calling it second-class can be seen as a stretch.

That's why it's called SQL aka String Query Language. The queries are just strings.
Post reply on HN