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

171–180 of 654 posts

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

#171

Post by berdon »

dillonmckay wrote: post #168
berdon wrote: post #156

Earlier quoted context omitted.

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?

No, both can dig but one gives you excruciating finesse (assembly/shovel). I’ve updated the ordering.

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

#172

Post by ummonk »

RangerScience wrote: post #158
berdon wrote: post #156

Earlier quoted context omitted.

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.

Why isn't your ORM using that same query builder library?

Why use a full ORM with everything it imposes when all you need is the query builder?

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

#173

Post by Glyptodon »

residentfoam wrote: post #110

I used ORMs JPA/Hibernate in several projects/teams and the outcome is always the same: things always get messy and overcomplicated, few reasons : - they push developers to design super-normalized db schemas that look beautiful on paper but are horrible in practice - the average developer has a very superficial knowledge of how ORMs work and this often leads to bad code/performance - soon or later you will find yours…

First your tree needs an apple, then it needs a pear, and then a fig, and after a year or two of grafting other things on you end up wishing you'd just created a cornucopia with a bunch of columns instead of joining a endless fruit because two thirds of the time you need a mix of the fruit anyway.

I'm definitely guilty of over-normalizing at least some of the time, but I'm less convinced that it's related to ORMs so much as it is to frequently having to build things without knowing how related they'll end up being in the future.

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

#174

Post by berdon »

RangerScience wrote: post #158
berdon wrote: post #156

Earlier quoted context omitted.

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.

Why isn't your ORM using that same query builder library?

It probably does. But the query builder doesn’t require architectural constraints, the ORM does.

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

#175

Post by BowBun »

jayd16 wrote: post #170
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.

Great comment. Whereas typical object models have many relationships and out of these, nested data, the optimization for SQL lies essentially in the other direction. Your DB should be optimized for speed, your code for use and readability. These are concepts, IMO, that are a classic trade-off against one another and it doesn't make sense to combine them into a single abstraction.

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

#176

Post by therein »

taffer wrote: post #169
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 mergin…

Yeah, basically an ORM is like a leaky abstraction over an already high abstraction and that's where the problem lies.

A better example would be having someone write C macros for you to implement your logic in. Like you can't call `open` to a get a file handle, you need to use the `WRITE_TO_ABSOLUTE_FILEPATH(path, content)` macro every time you wish to write something to a file because someone thought "you know, C is complicated and what are we gonna do, rewrite all uses of open every time we might want to use a different flag".

Comes with its own limitations while being sufficient for _some_ people's use cases.

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

#177

Post by dillonmckay »

daenz wrote: post #82
wvenable wrote: post #41

Earlier quoted context omitted.

That's not true. A simple job might be 3 lines of code in an ORM to update a record. In SQL that will be a lot more code especially if that's wiring up a foreign relationships. With SQL you will also have a lot of uncheckable strings containing code. Simple tasks are done maybe thousands of times in any one application. It's the complex tasks are rare.

>A simple job might be 3 lines of code in an ORM to update a record. In SQL that will be a lot more code especially if that's wiring up a foreign relationships. That's not a fair comparison unless you include the time and effort involved in creating your ORM models, before you can even write those 3 lines of ORM code. The effort to construct those models isn't even fully amortized over your project, since it must be…

This is by far the best ORM analogy yet.

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

#178

Post by tigershark »

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…

Ok, what kind of models are you working on? For me your comparison is completely unconceivable. I don’t like SQL so much, but I’m fairly certain at this point that the various ORMs are supposed to be an higher level abstraction but are in reality only an imperative facade over the mostly functional SQL language.

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

#179

Post by ummonk »

You have to distinguish between heavyweight ORMs that impose their own data model and lightweight ORMs which just provide transparent query builders and static typing for query calls from your given programming language.

The former is frustrating to use in my experience but the latter tends to make SQL easier to work with without taking away any of the power and expressiveness of SQL.

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

#180

Post by asdfaoeu »

falcolas wrote: post #155
timdev2 wrote: post #119

Earlier quoted context omitted.

> you automatically invalidate one of ORMs biggest selling points which is being SQL-database agnostic. I haven't heard anyone talk seriously about database-agnosticism since the very early 2000s. Maybe some commercial products still try (choose MS or Oracle!), but it's rare nowadays. The primary selling point of an ORM is that it abstracts marshaling/un-marshaling rows to/from entities. Instantiating and persisting…

> I haven't heard anyone talk seriously about database-agnosticism since the very early 2000s. Do you use the same database engine for your unit and integration testing as you do production? I don't. I use sqlite for unit and local integration testing, and aurora-mysql for production. As a side note, I quite literally can't use aurora-mysql for local unit and integration testing. It doesn't exist outside AWS.

> As a side note, I quite literally can't use aurora-mysql for local unit and integration testing. It doesn't exist outside AWS.

You can use mysql though...

Post reply on HN