Live data from Hacker News

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

woz.posthaven.com

11–20 of 360 posts

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

#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 when needed.

I don't think rails would have been as popular if you had to use SQL.

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

#14
I think saying "Just use SQL" is probably a bad idea. You'll most likely end up implementing an ORM anyway, or you will end up with your model code mixed up everywhere with your views.

I do think a lot of people use ORMs as a crutch, which sucks. Also, ORMs often provide too much abstraction, forcing people who actually know SQL to relearn how to do everything the way the ORM happens to like it. I should not have to learn twice as much to be productive due to an abstraction.

What I prefer are really lightweight ORMs that give me models which I can then enhance with custom code. I don't need an ORM that supports plugins or inheritance or a dozen different kinds of joins. All of that can be done more efficiently with custom code.

Also, I think SQL builders are really useful. I think a lot of people conflate SQL builders with ORMs but they're actually very different problems.

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

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

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.

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

#17
I'd rather learn the ins and outs, problems and issues, highs and lows, of SQL rather than an ORM.

ORM require just as much investment in time and even then you still need to learn the sql to get the ORM to do what you want it to do.

SQLAlchemy on Python is a truly fine piece of software but in the end it was much simpler and felt more powerful for me to write the SQL. And not even hard BTW.

I only have a limited amount of time available for learning and if I can trim out an entire class of technology (i.e. the ORM) then that's a whole bunch of stuff I just don't need to spend time learning.

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

#18
post #9

I prefer to use SQL directly as well. But some points to be made in favor of ORMs (some of them, anyway): * Multiple backend support to handle different SQL engines. * Minimized risk of accidental injection. * Migrations.

Migrations are orthogonal to ORMs.

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

#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.

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

#20

I don't hear people complaining about say LINQ. Maybe it's just that your language and/or ORM or integration thereof suck?

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 it is to not set up foreign keys which massively diminishes the value of using EF, so we wound up creating two copies of each table's classes, one with and one without foreign keys. That causes its own issues.

Post reply on HN