Live data from Hacker News

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

woz.posthaven.com

121–130 of 360 posts

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

#121

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.

Moving the definition of your sql from your app to the database doesn't impact scalability, as in both cases the database needs to perform the query.

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

#122
post #83

The most cringeworthy thing I heard about ORM's actually happened two weeks ago when I explained our use of a query builder rather than an ORM. The new senior developer was talking about speed (??? uhm… k...) and the benefit of being able to switch between PostgreSQL and... MongoDB. I just cringed up, didn't know what to say. Using the same domain model in an RDMBS as a Document Store? I really didn't know how to res…

ORM stands for Object-Relational Mapping (wikipedia). It is just a way to map domain objects to tables. There is no "promotion the use of state" in that definition. It is your choice to start using state in a (mis)designed manner but please don't blame ORMs for that.

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

#123
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…

4. The pain in the butt of writing and maintaining your own mapping code.

5. Type checking all your queries.

6. In code query composability.

But I totally agree that ORMs are too leaky of an abstraction for 2 to be really useful, and that 3 is much harder than it appears to be.

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

#124
It's not my quote but it goes along something like in order to use a layer of abstraction effectively you need to know 1 layer deeper.

Honestly what are you doing using an orm without knowing sql? The point isn't to hide sql, it's to automate repetitive tasks. Who goes to learn Angular.js without first knowing JavaScript or html?

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

#125
post #13

Why are we even having this debate? There are some ORMs that bring so much value to the table that you'd be stupid not to use them. Example being Django's ORM or SqlAlchemy. Also be specific in what ORM you are comparing to raw SQL. Are you talking about Hibernate or SQLAlchemy. Are you talking about a query builder? Good ORMs help tremendously with maintainability and security. They also let you drop down to raw SQL…

> Good ORMs help tremendously with maintainability and security.

ORMs don’t help with security compared to query builders or even typed text.

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

#126

Earlier quoted context omitted.

> ORMs are bad, because objects aren't particularly useful to deal with most data. Objects are containers of data; that's a crazy statement to make. The relational structure maps pretty cleanly to objects, properties, and collections. However, objects are not good for reporting. And the author mentioned doing 14 joins and hundreds of columns - that smells like a reporting query.

The relational structure maps cleanly to badly designed objects, where most classes have 5-10 fields and most fields are opaque data values with setters and getters. If you wrote classes like that in isolation, you'd have to do some serious work in code review, explaining why a hodgepodge collection of properties is a single unit of responsibility. But I've never worked in an ORM-using system where they weren't endem…

> The relational structure maps cleanly to badly designed objects

If you are exposing base tables to the application instead of appropriate views, which as much a violation of good RDBMS design principles as what you describe is a violation of good OO design.

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

#127

Earlier quoted context omitted.

Is it a good one, though?

Probably better than the one I could build by hand, with far better documentation, and greater ease in googling problems :)

while ORMs can do quite a bit of optimization, they're still general query builders and can't construct the optimal queries for your use case. if you don't know SQL, or you don't know what's going on behind the scenes, your ORM could be performing much larger queries than it really needs to, costing performance and time

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

#128
post #110

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…

> This is analogous to saying "don't use frameworks". Sound ridiculous? Yes, yes it is. When developing API's in Golang or for microservice / serverless architectures not using a framework might actually make a lot of sense. Also microframeworks (trimmed-down versions compared to opinionated frameworks) are very popular in almost any language.

There are such things as micro-ORM as well, btw. Still an ORM though.

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

#129
post #68

Earlier quoted context omitted.

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.

> ORMs are bad, because objects aren't particularly useful to deal with most data. Objects are containers of data; that's a crazy statement to make. The relational structure maps pretty cleanly to objects, properties, and collections. However, objects are not good for reporting. And the author mentioned doing 14 joins and hundreds of columns - that smells like a reporting query.

But why do you need these containers of data, when you could have more direct access to both the data itself and the whole set (not individual objects, nor collections of objects)

I dont like ORMs but did struggle some years trying to use them which imho was a detour. SQL and stored procedures in plpgsql is so much better, easier to maintain, easier to reason about etc.

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

#130
Many posts say that an ORM is a good idea for the type safety / vulnerability / composibility / portability aspects. But that’s actually independent from the object mapping aspects - e.g. web2py provides all of the above in its DAL without the object mapping. It does sort-of abstract over SQL variants with Python query syntax, but no objects are involved.

Nim’s Ormin is still in not fully functional but is providing the same in a static language with straight up SQL.

My experience is that the O aspect of ORM is where it doesn’t help (and often gets in the way); if that’s your experience, consider DAL and Ormin

Post reply on HN