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

61–70 of 305 posts

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

#61

Post by kennell »

dkarapetyan wrote: post #48

Never seen a large enough project that relies on an ORM be anything other than a giant mess. I mean never. The conclusion is correct. From an application perspective the db is just another API and should be treated that way and the ORM should just be thought of as a convenient DSL for creating queries on top of that API.

What do you define as "large enough"? There have been a ton of fairly big Ruby on Rails apps written over the last few years, the majority of them using ActiveRecord to handle everything.

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

#62

Post by rhizome »

dkarapetyan wrote: post #48

Never seen a large enough project that relies on an ORM be anything other than a giant mess. I mean never. The conclusion is correct. From an application perspective the db is just another API and should be treated that way and the ORM should just be thought of as a convenient DSL for creating queries on top of that API.

It strikes me as a thick/thin client tug of war. You can supplant ORMs by e.g. moving your logic into stored procedures on the db side, until you find an inconvenience there, then back and forth until the end of time. As with many dyadic architectural choices, there are good arguments on both sides.

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

#63

Post by krapp »

thomasahle wrote: post #52
StevePerkins wrote: post #34

Ten years ago, there was a blog post every other week bemoaning ORM's. Ten years ago, those posts often had merit. In 2016, this sentiment is outdated. A few points: 1. If you think that using an ORM means you don't have to learn SQL, then you're going to have a bad time. This is where most of the bad press originates... from people who never really learned SQL or their chosen ORM. An ORM provides type checking at yo…

> An ORM provides type checking at your application layer This. When composing complex queries, we really want type checking and SQL injection safety.

Unfortunately, ORMs sometimes undermine safety for the sake of convenience. Even ORMs which use parameterized queries (which any sane framework will) may be vulnerable if they build dynamic queries using string concatenation.

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

#64

Post by titanomachy »

PeCaN wrote: post #47
StevePerkins wrote: post #34

Ten years ago, there was a blog post every other week bemoaning ORM's. Ten years ago, those posts often had merit. In 2016, this sentiment is outdated. A few points: 1. If you think that using an ORM means you don't have to learn SQL, then you're going to have a bad time. This is where most of the bad press originates... from people who never really learned SQL or their chosen ORM. An ORM provides type checking at yo…

> If you're not using an ORM, then you ultimately end up writing one. I disagree with this. A lot of things people use ORMs for are rather easily solved with stored procedures, especially in Postgres where you can write stored procedures in Perl, Ruby, etc. Validations, “fat models”, etc are all managed with SQL easily (and this means you get that functionality from _anywhere you access the database_, not just from y…

How do you manage version-control on stored procedures? Can they be checked in with the rest of the application logic?

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

#65

Post by teacup50 »

StevePerkins wrote: post #34

Ten years ago, there was a blog post every other week bemoaning ORM's. Ten years ago, those posts often had merit. In 2016, this sentiment is outdated. A few points: 1. If you think that using an ORM means you don't have to learn SQL, then you're going to have a bad time. This is where most of the bad press originates... from people who never really learned SQL or their chosen ORM. An ORM provides type checking at yo…

> If you're not using an ORM, then you ultimately end up writing one.

Only if you assume that Object Relational Mapping is the only way to express type checked database access at the application layer.

ORMs are broken by design; there's no lossless bridge between relational theory and OO -- only inconsistent, error-prone, complex approximations.

Instead of bringing relational theory to the programming language, ORMs try to emulate OO behavior/method dispatch/etc in a world of transactions, deadlocks requiring retry of previous operations, on-disk serialization of data, etc.

In 2016, it's ORMs that are outdated.

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

#66

Post by sitharus »

titanomachy wrote: post #64
PeCaN wrote: post #47

Earlier quoted context omitted.

> If you're not using an ORM, then you ultimately end up writing one. I disagree with this. A lot of things people use ORMs for are rather easily solved with stored procedures, especially in Postgres where you can write stored procedures in Perl, Ruby, etc. Validations, “fat models”, etc are all managed with SQL easily (and this means you get that functionality from _anywhere you access the database_, not just from y…

How do you manage version-control on stored procedures? Can they be checked in with the rest of the application logic?

Yes, there are tools to do this. It varies by database server and may need custom integration with your deployment system but they definitely exist.

The alternative is the old StoredProc_v1, StoredProc_v2 etc in the database and have the application check what's available. This allows you to roll the parts independently.

The big advantage with stored procedures is they can benefit from the DBMS caching and applying additional optimisations (depending on the DBMS of course).

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

#67

Post by mb_72 »

vladsanchez wrote: post #17

I've always said: "ORMs are for people who don't know SQL!"

This doesn't ring true for me, at least - I've been programming professionally (using SQL) since the mid-90s, and these days very much appreciate the time-savings that ORMs (on Windows, for the most part) provide. With my favourite ORM - XPO from Developer Express - there is a decent tool for monitoring queries and sessions, and if I need to I can write custom SQL to improve performance (which almost never happens).

Another important point is that it's, IMO, much easier to maintain ORM-based code, and another programmer coming along after me can more easily get started on understanding what I've implemented. Once place I worked in the past we had a 'SQL guru' who wrote these massively complicated SQL queries that could be understood by no-one by him.

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

#68

Post by prodigal_erik »

zepolen wrote: post #37
fishtoaster wrote: post #31

Earlier quoted context omitted.

I completely agree. 90% of the queries in my app are no more complex than selecting from a table with a simple condition. I definitely find users = User.where(has_foo: true).limit(10) to be a lot more readable than rows = connection.exec_query("SELECT * FROM users WHERE has_foo=true LIMIT 10") users = rows.map { |row| User.build(row) } (And that's an example with no user-provided input) Likewise, any app of sufficien…

Here's the thing, anyone who knows SQL will find the second one readable, and only Ruby programmers who have used ActiveRecord will know how the first one does.

Unfortunately that argument works both ways, and we are saddled with a majority of mediocre developers who know an ORM but can barely read trivial SQL and can't really write it at all.

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

#69

Post by Something1234 »

nickpeterson wrote: post #44
greydius wrote: post #29

Earlier quoted context omitted.

In my limited experience with the enterprise world, the problem with using stored procedures was that the devs had no control over the database. We could have come up with some nicer solutions to certain problems, but no one wanted to deal with the bureaucracy necessary to create and maintain parts of our applications within the database.

Also Java and C# developers often produce bad SQL procedures because they tend to think procedurally about problems.

What would be the better thought process for writing sql procedures? It seems like PL/SQL is fairly procedural.

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

#70

Post by sopooneo »

titanomachy wrote: post #64
PeCaN wrote: post #47

Earlier quoted context omitted.

> If you're not using an ORM, then you ultimately end up writing one. I disagree with this. A lot of things people use ORMs for are rather easily solved with stored procedures, especially in Postgres where you can write stored procedures in Perl, Ruby, etc. Validations, “fat models”, etc are all managed with SQL easily (and this means you get that functionality from _anywhere you access the database_, not just from y…

How do you manage version-control on stored procedures? Can they be checked in with the rest of the application logic?

I myself am wary of stored procedures except in very specific and uncommon circumstances. That said, you could absolutely version control your stored procedures by creating them from within database migration files that are version controlled by default.
Post reply on HN