Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ORMs are nice but they are the wrong abstraction

workdad.dev

Post reply on HN
Print view View original

31–40 of 70 posts

Re: ORMs are nice but they are the wrong abstraction

#31

Post by sureglymop »

blagie wrote: post #16

The basic problem is that: 1) Relational databases are the best abstraction we've found for storing data. Despite years of attempts (OODB, XML databases, various nosql stores, etc.), we have not been able to improve on it. postgresql, by adding native JSON support, became a better mongo than mongo virtually overnight. 2) Most people never learn databases, and most people who do are idiots working on enterprise three-…

I learned about database theory a few times (and even interned as a DBA before I started uni). But it wasn't until my discrete math class in university that I finally understood, "oh, that's why we call a table a relation, a row a tuple, etc", and from there - started understanding the whole relational model and why it makes sense.

I think ORMs however, became a thing more so due to fear of having to write (correct) SQL. It was meant to reduce complexity for developers but of course that's not really how it panned out in reality.

Re: ORMs are nice but they are the wrong abstraction

#32

Post by Taikonerd »

The DB/ORM mismatch is worse than it has to be, because SQL queries always return flat rows. But in code, we don't usually want rows; we want objects linked to other objects: "get me the Account objects and their associated Wishlists."

If you use a query language that knows that we want objects linked to other objects, you can still have an ORM, but it doesn't have to do as much heavy lifting. The query can already specify the objects and properties you want explicitly, so you don't need to worry about, "which properties of which objects do I flesh? Am I over-fetching?"

That's why I've become a booster of EdgeDB: https://www.edgedb.com/ It's a sort of "midpoint" between regular SQL and an ORM. And it's language-agnostic, unlike an ORM.

Re: ORMs are nice but they are the wrong abstraction

#33

Post by ravenstine »

I dislike ORMs because they make big promises in exchange for giving up comtrol. I know this is one of those topics where someone may tell me I'm wrong and that I should be using some other ORM that truly does everything right. In my experience all ORMs have shortcomings and ultimately get in the way more than just writing SQL and constructing objects yourself, even though they can save time upfront.

Re: ORMs are nice but they are the wrong abstraction

#34

Post by jasfi »

blagie wrote: post #17
jasfi wrote: post #6

ORMs are useful when what you want to do matches their expressiveness. For example when I just want to get a record by its primary key. They have their limits, many times when doing complex reports. For that, most ORMs provide a raw SQL function. So just use the right tool for the job. Stored procedures for business logic can be great for performance when they replace queries/mutations called thousands+ times.

ORMs are nice for "Hello World," and hit a brick wall later. I don't mind them for simple systems, but for more complex systems which need SQL, don't use an ORM. Mixing ORMs with raw SQL generally mixes and breaks layers of abstraction. This leads to a situation where the overall system is more complex than having a sane relational abstraction. For example, ORMs do a lot implicitly. A code change at the language leve…

Then you'd never use an ORM, because you might require something an ORM can't handle at some point. I don't see why a coder couldn't handle a mix of both. The other factor is that ORMs tend to add features over time. Something that would require raw SQL today might be more elegantly handled with an ORM's language two years from now.

Re: ORMs are nice but they are the wrong abstraction

#35

Post by nunez »

ORMs are very similar to the back and forth on using ChatGPT/Copilot for coding; they definitely help make it easier to leverage a database and model data within an application, at the cost of becoming further decoupled from SQL and how the data actually lands into the database.

i personally avoid them, but i don't often write complex SQL

Re: ORMs are nice but they are the wrong abstraction

#36

Post by nunez »

kgbcia wrote: post #5

How about move the business logic to stored procedures

that's also nightmare enducing since sql is great for interacting with data but less great at expressing how that data should be stored and the relationships within the data. this worsens quickly the more complex the business logic gets.

stored procs also tie you to that database engine, which could be bad if, for example, you're paying a fat stack of cash to oracle and they come back asking for more.

i think a business logic api in a programming language that leverages raw SQL is the best middle-ground IMO.

Re: ORMs are nice but they are the wrong abstraction

#38

Post by random_kris »

blagie wrote: post #16

The basic problem is that: 1) Relational databases are the best abstraction we've found for storing data. Despite years of attempts (OODB, XML databases, various nosql stores, etc.), we have not been able to improve on it. postgresql, by adding native JSON support, became a better mongo than mongo virtually overnight. 2) Most people never learn databases, and most people who do are idiots working on enterprise three-…

https://orm.drizzle.team/ Basically this ?

Re: ORMs are nice but they are the wrong abstraction

#39

Post by OJFord »

nunez wrote: post #35

ORMs are very similar to the back and forth on using ChatGPT/Copilot for coding; they definitely help make it easier to leverage a database and model data within an application, at the cost of becoming further decoupled from SQL and how the data actually lands into the database. i personally avoid them, but i don't often write complex SQL

Complex SQL is when you need to avoid them - at a certain point you hit the limit of what the ORM thought to support.

Re: ORMs are nice but they are the wrong abstraction

#40

Post by everforward »

blagie wrote: post #16

The basic problem is that: 1) Relational databases are the best abstraction we've found for storing data. Despite years of attempts (OODB, XML databases, various nosql stores, etc.), we have not been able to improve on it. postgresql, by adding native JSON support, became a better mongo than mongo virtually overnight. 2) Most people never learn databases, and most people who do are idiots working on enterprise three-…

https://GitHub.com/masterminds/squirrel sounds like what you want, in Go at least. They bill it as a SQL query builder instead of an ORM.

It lets you build SQL queries using code and just returns the built SQL query as a string, the list of variables to pass into the query, and an error if your query was invalid.

Actually executing the query and doing stuff with the result is explicitly outside their scope. I typically use it with sqlx with a struct per query, just to avoid writing tedious row iterators.

Makes it super easy to eg define a function that adds paging to a query and returns the paged query. You can even write a function that takes an HTTP request, reads out standard paging parameters and adds them to a query.

Post reply on HN