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

161–170 of 654 posts

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

#161

Post by [deleted] »

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.

[deleted]

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

#162

Post by Glyptodon »

breatheoften wrote: post #124
fabiosussetto wrote: post #88

I think there's often an underlying confusion between different tools and what they are supposed to do. An ORM - as the acronym says - is helpful to map database records to objects in the system. The meaning of the acronym already says that an ORM is not really designed for scenarios like aggregations and reporting. Within those contexts, you don't normally reason in terms of list of "objects" and "relationships" bet…

Query builders can be so good at making it easy to work with the database ... the popularity of ORMs over query builders is a really big collective reasoning failure in my opinion. With a good query builder in hand - it is very unclear to me why anyone would ever want to use an orm.

I like query builders but if everything were done with query builders there'd still be an awful lot of DRY pertaining to business logic that needs to go somewhere. Maybe you replace the ORM with some sort of 'results act as ' abstraction, but things like that often work out much better with consistent scaffolding of some sort, which is mostly what successful ORMs seem to be.

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

#163

Post by ratww »

Nican wrote: post #125
tracker1 wrote: post #121

On a recent project, it was a weird inversion in terms of access... in order to keep the middle tier thin, and meet requirements that all data access happen through stored procedures... we pretty much standardized an interface with one input parameter (@json) and two output parameters (@result, @errorResult). In the end, all input/output was JSON and the database handled all data internally. I don't really like it mu…

It was not the first time I heard the requirement about "all data access happen through stored procedures", and I find it ludicrous. Does anyone know how such a paradigm came to exist? What problem is this solving?

I remember it being common in the 90s and 2000s, when DBAs were primarily developers.

It's absurdly overkill if you're just doing CRUD, but if the DB uses some crazy schema that doesn't match the usage it keeps you sane.

One such project I worked in had a primitive form of event sourcing built in. Everything was logged and could be replayed. It was kinda neat.

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

#164

Post by hombre_fatal »

qes wrote: post #118
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…

> I’m shocked at how many people have issues with ORMs Simple inexperience. I'd bet most of those people are mid-level developers who have used ORMs enough to hit the rough edges but not enough, or with enough independent agency, to have worked through how to play to ORM's strengths while avoiding their weaknesses. People that were given a hammer and are just understanding that their hammer doesn't work very well to…

It's condescending and convenient for you to discount the people who disagree with you as merely inexperienced.

You could level the same empty claim at people who like ORMs: I loved ORMs when I was a beginner but learned it's best to avoid them as I accumulated experience. So anyone who likes ORMs is merely in that beginner stage.

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

#165

Post by honkycat »

kuon wrote: post #78

I mostly agree. But lately I've been using Ecto, and I like the approach. It's mostly an SQL generator. So far it's the sanest approach to ORM I've used.

Agreed. Awesome abstraction that lets you build on top of it while still using low level SQL when warranted

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

#166

Post by _bxg1 »

In my opinion this whole problem is one of the strongest condemnations of OOP. Even if OOP really were a great way to model your data, to express relationships and property types and such (setting aside all the questionability of that claim), it's all just going to end up in a database anyway. Unless you're using a denormalized database like Mongo, or the bulk of your application state is non-persistent, your perfectly thought-out OOP model is at best going to be a terrible approximation of the real data model and you're much better off using a language/paradigm that lets you just treat data as data.

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

#167

Post by orware »

I've looked at ORMS mostly on the periphery for years and years now, but haven't really been able to use them in our environment and this might be similar to the situation for others as well.

One thing I noticed early on, is that even using a query builder complicated things a bit as well since it meant that the original SQL string was then broken up into multiple method calls to construct the SQL string. Since the full query wasn't built until the very end, this meant that a helper line needed to be added into the code to get that full SQL query if any issues were found down the road and then taken over into our program of choice (in this case, SQL Developer, since we're dealing with Oracle queries in most cases) and running our additional tests over there.

Our campus ERP is pretty complicated table-wise, so our queries (developed either by myself or by our systems analysts) tend to be fairly complex, requiring multiple joins and other complex logic that I feel would have a very difficult time being translated into an ORM format.

A query builder is still somewhat usable, but for the most part I just stick to mostly straight up SQL queries and make use of prepared statements to help avoid SQL injection and keep life simple so it's easier to move back and forth between the application side and testing the query on the database side :-).

On a side note, I'm not sure if it's mentioned here in the discussion (and it might be less of an issue now than in years past) but I have noted some ORM usage doesn't always choose the most efficient mechanism for things (e.g. pulling results using small, but relatively expensive multiple SQL queries rather than being contextually savvy enough to know that a set-based query would be better suited to retrieve the entire set of results at once).

Overall though, working with SQL and coming up with solutions for things is probably one of the funner aspects of my current position and while using an ORM has sounded like fun in the past, it just hasn't seemed like it's the best fit for our particular workflow/environment.

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

#168

Post by dillonmckay »

berdon wrote: post #156
kbenson wrote: post #143

Advocating for the use of SQL over an ORM in every case is like advocating for the use of Assembly over C in every case. In both cases, one is a higher level abstraction over the lower level capabilities, which can provide a quite large gain in usability and ability to easily understand what is going on at the level you are working at, for the loss of hand optimizing at a low level to get just what you want in every…

Your assembly/c analogy is more akin to comparing a shovel to a mini excavator. 95% of the time you’re better off using a query builder library for the convenience rather than locking your architecture into using an ORM that will, inevitably, cause long term headaches. For the other 5% of the time, you’re just building a todo app, use whatever fancy general purpose libraries are hot at the moment.

So, SQL is the shovel, correct?

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

#169

Post by taffer »

kbenson wrote: post #143

Advocating for the use of SQL over an ORM in every case is like advocating for the use of Assembly over C in every case. In both cases, one is a higher level abstraction over the lower level capabilities, which can provide a quite large gain in usability and ability to easily understand what is going on at the level you are working at, for the loss of hand optimizing at a low level to get just what you want in every…

> Advocating for the use of SQL over an ORM in every case is like advocating for the use of Assembly over C in every case.

Comparing SQL to Assembly is probably one of the worst comparisons you can make. SQL is a very high-level and powerful declarative language that I would compare, if at all, with functional languages and not with assembly. A few lines of SQL are counting, sorting, grouping, aggregating, and merging data that would take dozens of lines if written row by row in a procedural language.

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

#170

Post by jayd16 »

kbenson wrote: post #143

Advocating for the use of SQL over an ORM in every case is like advocating for the use of Assembly over C in every case. In both cases, one is a higher level abstraction over the lower level capabilities, which can provide a quite large gain in usability and ability to easily understand what is going on at the level you are working at, for the loss of hand optimizing at a low level to get just what you want in every…

Its really not though. C is just sugary Assembly that abstracts some things but the design patterns are aligned. ORMs promote a fundamental mistake of coupling your object model to your normalized data model.
Post reply on HN