Live data from Hacker News

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

woz.posthaven.com

61–70 of 360 posts

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

#61
post #43

> If you're using an RDBMS, bite the bullet and learn SQL. If this person spent all that time using Hibernate and then SQLAlchemy, and all that time did not know SQL, then their suffering and bad experiences make complete sense. You absolutely need to know SQL if you're going to use an ORM effectively. Good ORMs are there to automate the repetitive tasks of composing largely boilerplate DML statements, facilitating q…

I think there are 3 main reasons ORMs came into common use:

1. As a reaction to common SQL injection from poor libraries not implementing parameterized queries. (2004 or so)

2. Novice engineers not wanting to learn SQL (look I learned how to make a blog in RoR, and I like mongo!)

3. As a theoretical abstraction above the data-store (as though you might someday be able to switch the data-store beneath the ORM)

1 has been solved, 2 was never okay (point of the article), and 3 isn't really okay either because it's too leaky (performance specifics).

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

#63

Earlier quoted context omitted.

I've used SQLalchemy a lot. I've even written a keyset paging extension for SQLalchemy. But recently I've switched to writing stored procedures and calling them directly, instead of going through an ORM for everything... And it's so much easier.

One problem with having logic in the DB is that it's much harder to scale if you need 10x more computing power.

Scaling is like optimization in general: not everything will need to be able to scale, and even if they will, they often do not need to scale yet.

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

#64
post #19

Object -relational mapping is in many cases an excessively leaky abstraction. I try keep away from it. A DSL for writing SQL in a nice, composable way is a useful thing. Some libraries, like SQLAlchemy, provide both levels, not insisting on using the object mapper.

The DSL for your database is called SQL.

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

#65
post #43

> If you're using an RDBMS, bite the bullet and learn SQL. If this person spent all that time using Hibernate and then SQLAlchemy, and all that time did not know SQL, then their suffering and bad experiences make complete sense. You absolutely need to know SQL if you're going to use an ORM effectively. Good ORMs are there to automate the repetitive tasks of composing largely boilerplate DML statements, facilitating q…

I think there are 3 main reasons ORMs came into common use: 1. As a reaction to common SQL injection from poor libraries not implementing parameterized queries. (2004 or so) 2. Novice engineers not wanting to learn SQL (look I learned how to make a blog in RoR, and I like mongo!) 3. As a theoretical abstraction above the data-store (as though you might someday be able to switch the data-store beneath the ORM) 1 has b…

For 3: the proper abstraction for relational data is, surprise, a relation.

I used to work in an environment where we had relations as full first class data structures. They are very pleasant to work with.

We actually had 'relation-object-mappers', ie when we had to interact with other systems that didn't use relations, we often mapped them to relations internally to make them play nicer.

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

#66
post #5

A lot of the reasons listed in this article actually made me shift from sophisticated ORMs like Hibernate back to a query based approach. A really nice framework for this (in Java) is jOOQ which gives you the possibility to write typesafe SQL via code generation. https://www.jooq.org/ (I'm not at all affiliated with jOOQ - just a happy user)

Another happy jOOQ user here! I'm ditching Hibernate wherever I can in favour of it. And using it with Kotlin instead of Java makes it almost a form of poetry.. I've seriously been thinking about writing a blog post, something along the lines of "jOOQ: how I learned to love the database again"

I've been thinking about what makes jOOQ so good and a huge part of it is brilliant engineering: SQL clauses are mapped almost 1:1 into reasonable and understandable code while the author spends huge effort to cover new features as databases introduce them without turning his product into a mess or introducing API breaks in every major new version. That's hard.. but awesome! :)

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

#67
post #50

Earlier quoted context omitted.

LINQ isn't a ORM. I assume you mean Entity Framework? EF definitely has the foreign key issue. We have around a thousand tables, we tried to generate the classes for all of them including foreign keys, problem is that when you create a context that references even only a single table, it will load everything that is foreign keyed including siblings of siblings of siblings, until you run out of memory. Only way around…

Sounds like you disabled lazy loading and that forced everything to be loaded at once. That's a user error, not a EF fault. This is a common theme I've seen with people blaming ORM's for being slow, it's the devs not using them appropriately more than the ORM's themselves. Not to say that they don't have their own issues.

With or without lazy loading enabled the result was the same. Generating the structure took seconds and went OOM with enough tables.

LazyLoading impacts what data is retrieved from the database (or more to the point when), this is a structural issue before a query was even sent to the database. It would die while generating the query, not sending the query or populating the result.

You likely should have asked for more information before concluding it was "user error."

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

#68

Ah yes - the proverbial "ORMs are bad, just learn SQL" post. This is analogous to saying "don't use frameworks". Sound ridiculous? Yes, yes it is. The law of leaky abstractions applies to many, many things, ORMs included. I would also argue they apply in different degrees, usually related to the design of the ORM (the post mentions SQLAlchemy vs. Hibernate, for example). But consider the following: 1) Why do people s…

ORMs are bad, because objects aren't particularly useful to deal with most data.

And when you've already been through the effort to make your data relational for the database, might as well re-use that effort.

That's not to say that SQL is the answer. Proper first class support for relations in your programming language / libraries is great.

As for using a DSL, Datalog is worth a look.

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

#69

Ah yes - the proverbial "ORMs are bad, just learn SQL" post. This is analogous to saying "don't use frameworks". Sound ridiculous? Yes, yes it is. The law of leaky abstractions applies to many, many things, ORMs included. I would also argue they apply in different degrees, usually related to the design of the ORM (the post mentions SQLAlchemy vs. Hibernate, for example). But consider the following: 1) Why do people s…

In response to (4). I'd posit that beginners have a hard time with this stuff because they use too many leaky abstractions. Like the article says, if you want to use an ORM for anything non-trivial, you need to learn both the ORM and SQL, which is inherently more difficult than just learning SQL.

Providing tons of abstractions to beginners so they can build something in 10 lines of code doesn't help them get better. All it does is encourage them to learn top-down when it's often much easier to learn something from the bottom-up.

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

#70
post #57

The post is from 2014, so I won't be too harsh here. The author's problem is with some specific flavors of ORM he's used, and shouldn't be generalized. Hibernate's expressiveness is/was crippled by Java itself. C# ORMs on the other hand are way better because they benefit from LINQ which adds queries natively into the language. Other more expressive languages have excellent ORMs as well. The objective of ORMs is not…

Is LINQ actually an ORM? It looks like a DSL to do relational stuff in C#, but I don't see where the 'O' part of ORM fits in especially not in your examples to show off LINQ's power and convenience.
Post reply on HN