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

271–280 of 354 posts

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

#271

Post by gigatexal »

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

With a few extra lines and mapping objects to classes this can be done.

To have all this ease of use you give up so much in performance.

Most apps and companies never get to the point where performance matters that’s why we have ORMs.

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

#272

Post by dpedu »

I'm totally on board with the idea that ORMs create a variety of inefficiencies, pain points, and make it really easy to create bad queries or querying strategies. But I use them anyways because the convenience of mapping a row to a code object makes writing programs feel fast and simple. And if you know how ORMs can cause problems and how to watch out for them, you can still get a lot of mileage out of them.

That being said, what's the closest alternative that satisfies this - "mapping rows to a code object" - that doesn't suffer the same problems as an ORM? A middle ground between an ORM (like SQLAlchemy, for example) and "your rows are returned as a key/value dictionary where the column names are keys" type approach like Python's DB-API's DictCursor or PHP's mysqli_fetch_assoc. Is there a middle ground here?

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

#273

Post by webstrand »

mattmanser wrote: post #262
Kon5ole wrote: post #240

Earlier quoted context omitted.

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

That doesn't sound at all like any ORM I've ever used. I've struggled in the past because The ones I've used are actively hostile to laying out data in the database in a way not proscribed by the ORMs philosophy. Heck of the ORMs I've used, one didn't support parameterized joins and the other didn't support joins at all.

---

It's not usually a DB guy gatekeeping, it's that multiple apps use the same database so layout changes are costly.

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

#274

Post by datsci_est_2015 »

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.

> you’ll inevitably come up against a situation where a custom query gets the job done better

In my experience, these are typically best turned into views (or materialized views), because they represent some fundamental relationship or property within the data that’s useful to be able to quickly reference or query directly against. KPI aggregates, for example.

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

#275

Post by win311fwg »

dpedu wrote: post #272

I'm totally on board with the idea that ORMs create a variety of inefficiencies, pain points, and make it really easy to create bad queries or querying strategies. But I use them anyways because the convenience of mapping a row to a code object makes writing programs feel fast and simple. And if you know how ORMs can cause problems and how to watch out for them, you can still get a lot of mileage out of them. That be…

No, there is no middle ground. You can either maintain relations throughout the full application or you can transform them into application-native structures, the latter of which is ORM.

The article seems to be confusing ORM with query builders. Query builders are where you might avoid writing SQL. ORM is a data transformation technique.

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

#276

Post by dominotw »

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

its a good abstraction if you build it yourself.

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

#278

Post by revetkn »

argentinian wrote: post #256
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.

Is it very similar to the relatively new jdbcClient from Spring framework? https://www.danvega.dev/blog/spring-jdbc-client

Yes - the JdbcClient API has a similar feel for sure. If you are using Spring, it is a better choice than Pyranid because it integrates well with the Spring txn plumbing. Outside of Spring, I think Pyranid has a lot of advantages.

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

#279

Post by bsuvc »

dpedu wrote: post #272

I'm totally on board with the idea that ORMs create a variety of inefficiencies, pain points, and make it really easy to create bad queries or querying strategies. But I use them anyways because the convenience of mapping a row to a code object makes writing programs feel fast and simple. And if you know how ORMs can cause problems and how to watch out for them, you can still get a lot of mileage out of them. That be…

In .NET, I think Dapper comes closest to what you are describing. It does the object mapping, but you still write the queries as SQL.

https://github.com/DapperLib/Dapper

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

#280

Post by bartread »

simondotau wrote: post #267
bartread wrote: post #257

Earlier quoted context omitted.

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

All of this depends on the problems you’re solving though. There is no one size fits all approach to database development.
Post reply on HN