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 654 posts

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

#61

Post by wvenable »

geophile wrote: post #44
wvenable wrote: post #30

Earlier quoted context omitted.

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…

ORMs make the simple things simple, and the complicated things impossible.

ORMs let you drop into SQL whenever you need, usually in a way that is fully compatible with the model, so that's entirely false.

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

#63

Post by mindcrime »

geophile wrote: post #44
wvenable wrote: post #30

Earlier quoted context omitted.

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…

ORMs make the simple things simple, and the complicated things impossible.

A. that's not even close to true, and

B. if it were, that only argues that you don't use the ORM in the latter case.

You can have an ORM in your project and still fall back to plain old SQL if you like. It's not an "either-or" thing.

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

#64

Post by geophile »

trjordan wrote: post #10

Code thinks in objects and functions and values and pointers. Databases think in tables and columns and rows and queries and indexes. If you don't pick an ORM to help manage this translation layer, then you'll end up re-implementing your own. Maybe this is OK, because yours will be simpler for quite some time. What else are you going to do? Stored procedures? Concatenated strings?

No, you don't end up re-implementing your own, you end up implementing 10% of one. The 10% you need. Maybe it maps rows to objects, but doesn't handle object identity right, because that's not what you need.

The ideal for me is something that manages connections, lets me write the SQL, and gives me easy access to ResultSets, perhaps in the form of an object.

And yes, stored procedures are extremely useful, especially for minimizing chatter between the server and the database. Use them appropriately. (Although I don't see how they are an alternative to ORMs.)

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

#65

Post by mavelikara »

invokestatic wrote: post #27

This topic pops up frequently here on HN and every time I’m shocked at how many people have issues with ORMs! I’ve been using Hibernate/Spring Data for several years now and never ran into any issues. If I need to write a complex query, I can easily write a @Query annotation in HQL and it neatly fits right in to the repository class. I also develop with query logging enabled so I have better understanding of the quer…

Same here. Hibernate team had always, even as early as 2003 when I first started using it, advocated for turning on show_sql=true in development. If the code interacting with the DB fetches a table - rows and columns - of data, say for displaying a report, ORM does not buy you much. Instead, if the code converts the ResultSet to entities in an OO language you always end up using an ORM - a hand-rolled one, or an off-the-shelf one. I just don't understand the hate.

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

#66

Post by Roboprog »

DoreenMichele wrote: post #49
Roboprog wrote: post #42

Earlier quoted context omitted.

I know, this is a recurring discussion. Both sides continue to distrust the other, though.

Listing prior discussions is not a reprimand suggesting we can't discuss it again. It's a service to the community to let us see what's already been said, if we so desire.

Ah, thanks.

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

#67

Post by mindcrime »

invokestatic wrote: post #27

This topic pops up frequently here on HN and every time I’m shocked at how many people have issues with ORMs! I’ve been using Hibernate/Spring Data for several years now and never ran into any issues. If I need to write a complex query, I can easily write a @Query annotation in HQL and it neatly fits right in to the repository class. I also develop with query logging enabled so I have better understanding of the quer…

This topic pops up frequently here on HN and every time I’m shocked at how many people have issues with ORMs! I’ve been using Hibernate/Spring Data for several years now and never ran into any issues.

Same. Hibernate with Spring Data JPA, for me, "just works". But it's not necessarily the right solution for every database interaction. But for a typical microservice which might have up to 20-25 discrete entities, and few if any crazy complex relationships, I find that I plug it in, extend CrudRepository, write some JPQL queries in @Query annotations here and there, and bob's yer uncle.

If you were writing a monolithic CRM system with 900 domain entities, super complex rules governing the inter-relations between them, and trying to write your analytics queries right into the app, then an ORM approach would probably fail miserably.

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

#68

Post by xienze »

I feel like there should be a better term to distinguish an ORM framework from the kind of ORM that pretty much every competent developer uses (a hand-rolled one).

These “you don’t need an ORM!!!” posts always annoy me because even if you don’t think you’re using an ORM, you probably are. You aren’t mixing raw SQL statements into your business logic, are you? Probably not. You’re probably writing wrapper classes that “map” the “relational” data into the “objects” that your business logic uses, otherwise known as an ORM.

But there’s a big difference between that and an ORM framework that generates SQL. Realistically speaking, you _do_ need an ORM in all cases, but not necessarily an ORM framework.

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

#69

Post by hdfbdtbcdg »

JimmyRuska wrote: post #16

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

Someone who writes that in an ORM will happily write the same loop with sql in the middle.

ORMs usually have eager loading options...

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

#70

Post by _frkl »

hashkb wrote: post #5

SQL just isn't composable. I know this article is old, but these days it's not black and white. In the space between ORM and raw SQL there are things like AREL which can save a ton of dev effort without the "impedance mismatch".

Neat, not having used rails ever, I didn't know about Arel. Speaking about composable sql, I've had some good success with dbt lately. It has a feature where it lets you 'compile' a query out of multiple select models. Now I wonder whether it'd be feasible to use that dynamically, within the context of an application...
Post reply on HN