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

261–270 of 354 posts

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

#261

Post by thr0w »

iamflimflam1 wrote: post #241

Feels like everyone has to go on the journey. ORMs are bad - I’ll just use SQL. Hmm - I need to map these results onto objects I can use. Hmm - wouldn’t it be great if the object tracked changes and could save itself. I need related/child objects - wouldn’t it be great if I could auto fetch them. …

> Hmm - I need to map these results onto objects I can use.

What sql client is going to hand you raw text?

> Hmm - wouldn’t it be great if the object tracked changes and could save itself.

Lost me there.

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

#262

Post by mattmanser »

Kon5ole wrote: post #240
Exoristos wrote: post #212

Earlier quoted context omitted.

Why is your database so different from your domain?

>Why is your database so different from your domain? Usually it's due to one of these: - The domain deals with a lot of things that are not in the database. - The domain is one of many and deals with just a fraction of what is in the database. - The domain deals with things stored in several databases. - The database was designed in the 90s and the domain is new. - It's not my database so I can't change it. (Even for…

It's not that your domain is different, it sounds more like you don't know how to use ORMs. ORMs don't have to manage migrations, they don't have to even write into the database. When dealing with a bad database design, it can be a legitimate tactic to use ORMs in read-only mode and have writes still as hand-rolled SQL. You can do database-first ORMs, as well as code-first, where the database design is king, not the POCO.

> The domain deals with a lot of things that are not in the database.

You can have non-serialized properties. You can even can over-ride serialization/de-serialization of individual properties

> The domain is one of many and deals with just a fraction of what is in the database

You can use different ORMs for different parts of your domain, you could even wrap multiple ORMs in a wrapper repo pattern if you want

> The domain deals with things stored in several databases

As above.

> The database was designed in the 90s and the domain is new

Tons of solutions for this, one easy one is using SQL Views, just ask Claude. The weird thing here is that I've now dealt with this IRL like 5 times and came to the opposite conclusion of you. I found wrapping a bad DB design with an ORM a great first step in fixing it, as the ORM effectively acts as an easy strangler pattern.

> It's not my database so I can't change it

You can still use ORMs, ORMs don't have to manage migrations. Though I feel sorry for you working somewhere you still have a DB guy gatekeeping the database design in 2026.

The point is, every one of your objections are pretty trivially solvable with many mature ORMs, because everyone else had the same problems two decades ago and instead of throwing up their hands and hand-rolling their SQL, the ORM tooling was improved.

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

#263

Post by watwut »

simondotau wrote: post #260
iamflimflam1 wrote: post #241

Feels like everyone has to go on the journey. ORMs are bad - I’ll just use SQL. Hmm - I need to map these results onto objects I can use. Hmm - wouldn’t it be great if the object tracked changes and could save itself. I need related/child objects - wouldn’t it be great if I could auto fetch them. …

I think that journey only feels inevitable if you start from the assumption that the application object model is the centre of the system. An alternative journey: Hmm – I should model the data according to the domain, not according to the shape my application objects happen to want. Hmm – maybe “related objects” are not things to auto-fetch, but relationships the database engine is already built to handle. Hmm – now…

None of your points remove the need to map db values to objects and to fetch related objects.

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

#264

Post by watwut »

setr wrote: post #176
nodamage wrote: post #174

People have been making these same arguments for decades and at this point I'm convinced they are all based on the same strawman: That ORM's absolve you from having to learn SQL. Once you understand that was never actually true to begin with you can treat the ORM as a tool that simply helps you generate repetitive boilerplate queries and hydrates result rows back into objects for you. Furthermore, if your objects are…

The problem with ORMs are 1. They pretend SQL is standardized, and support a heavily reduced featureset for any given database as a result 2. They leave awkward holes in their abstraction, leading to psychotic behaviors like N+1 and implicit type coercions to helpfully break your indexes silently 3. They make simple queries simple, and hard queries absolutely revolting 4. You end up not wanting to use the objects dir…

I find the 1, 2 and 3 to be complete non issues. As in, they dont exist as issues for hibernate. If you feel like particulat query is oh so difficult, you can always use sql for that one part.

4 is in the "like so what" category.

5 - it optimizes alright for average case. You have to optimize in edge cases, but then again, you have to optimize edge cases with pure sql too.

6 - no I dont want much inheritance in db whether i am using pure sql or orm.

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

#265

Post by bogdan »

thr0w wrote: post #261
iamflimflam1 wrote: post #241

Feels like everyone has to go on the journey. ORMs are bad - I’ll just use SQL. Hmm - I need to map these results onto objects I can use. Hmm - wouldn’t it be great if the object tracked changes and could save itself. I need related/child objects - wouldn’t it be great if I could auto fetch them. …

> Hmm - I need to map these results onto objects I can use. What sql client is going to hand you raw text? > Hmm - wouldn’t it be great if the object tracked changes and could save itself. Lost me there.

Entities

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

#267

Post by simondotau »

bartread wrote: post #257
inigyou wrote: post #253

Earlier quoted context omitted.

ultimately, there is no silver shortcut - you just have to write the damn code

Yeah, exactly. I think the best approach is always to know SQL and know the ORM. Most of the time you’ll be able to simply use the ORM, but every so often you’ll inevitably come up against a situation where a custom query gets the job done better, and you’ll still get the benefits of deserialising to objects that the ORM offers.

As long as you restrict yourself to an ORM-compatible schema, you are restricting the power of SQL available to you. Learning SQL properly means learning to model your data correctly, and this usually makes ORMs a non-starter.

Without an ORM you have to write a bit more boilerplate code to interact with the database. But by taking advantage of the power of your database engine, you could potentially avoid writing huge amounts of data manipulation logic. In my experience, an ORM is more of a code amplifier than a code simplifier.

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

#268

Post by atomicnumber3 »

iamflimflam1 wrote: post #241

Feels like everyone has to go on the journey. ORMs are bad - I’ll just use SQL. Hmm - I need to map these results onto objects I can use. Hmm - wouldn’t it be great if the object tracked changes and could save itself. I need related/child objects - wouldn’t it be great if I could auto fetch them. …

It's not one or the other, it's both. Sqlalchemy ORM is my favorite, followed sqlc (golang), because they are both there for you for your highs (select * from table order by created at) and your lows ([an inner join followed by 4 left joins with an aggregation function])

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

#269

Post by simondotau »

watwut wrote: post #263
simondotau wrote: post #260

Earlier quoted context omitted.

I think that journey only feels inevitable if you start from the assumption that the application object model is the centre of the system. An alternative journey: Hmm – I should model the data according to the domain, not according to the shape my application objects happen to want. Hmm – maybe “related objects” are not things to auto-fetch, but relationships the database engine is already built to handle. Hmm – now…

None of your points remove the need to map db values to objects and to fetch related objects.

If you just want to store and retrieve objects, and then store and retrieve "related" objects, what you want is an object store, not a relational database. You can use an ORM to shoehorn it into a relational database engine, but don't fool yourself into thinking that's the same thing as using a relational database engine properly.

Obsessively cramming tabular data into objects is often unnecessary, and it bloats the code downstream of the database query. It then encourages the bad habit of performing data manipulation in code rather than directly in the database.

"Fetch related objects" is a code smell. If any related data was needed, your original query should have already fetched it.

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

#270

Post by getnormality »

dang wrote: post #185

Related: What ORMs have taught me: just learn SQL - https://news.ycombinator.com/item?id=28812506 - Oct 2021 (24 comments) What ORMs Have Taught Me: Just Learn SQL (2014) - https://news.ycombinator.com/item?id=24845300 - Oct 2020 (291 comments) What ORMs have taught me: just learn SQL (2014) - https://news.ycombinator.com/item?id=21031187 - Sept 2019 (634 comments) What ORMs have taught me: just learn SQL (2014) - ht…

Seems like we needed an annual meditation on this topic until 2021, then we took a 5 year hiatus? What happened?
Post reply on HN