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

231–240 of 305 posts

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

#231

Post by collyw »

khorpy wrote: post #220

When considering using ORM we need to answer simple questions: does it help to decrease code size? In most cases ORM code is same size as SQL query. Secondly, does it hide complexity? No, it just adds up one more layer that in fact increases complexity and makes it harder to debug. Finally, does it protect us from errors or impoves code quality? This is rarely the case. Instead of using ORM I prefer moving data retri…

In most cases its smaller (in the Django ORM anyway).

myobject, created = MyObject.objects.get_or_create(field1='1' , field2=field2)

That would take a number of lines. One query to check if the object exists, another to create it / retrieve it, plus application code to deal with that SQL.

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

#232

Post by lmm »

int_19h wrote: post #229
lmm wrote: post #205

Earlier quoted context omitted.

More like relational databases are outdated. There was one truly committed effort to bring the database model into the programming language - EJB - and there's a reason it's now a curse word. The successful systems of the past ten years have been those that moved away from the relational model, using simple datastores controlled by application code.

I'd bet that there is more code written in the past 10 years that uses SQL, than that which uses "simple datastores". You don't hear it much, because it just works, all the problems are well known (and so are the various solutions & workarounds), and so it's boring. Whereas, "Company X has adopted No-SQL solution Y for its project Z! That means it works!" makes headlines.

Probably true as far as it goes. But I think that SQL is a smaller percentage of systems now than it was 10 years ago, and that the trend continues to be in that direction.

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

#233

Post by jeltz »

fbonetti wrote: post #30
sirn wrote: post #5

Earlier quoted context omitted.

But how do you do: SELECT posts.*, (SELECT COUNT(1) FROM comments WHERE post_id = posts.id) AS comments_count FROM posts; In ActiveRecord, without 1+N queries, or caching comments_count in a column somewhere? Admittedly, that was not the best example. The last time I need something more intertwined than a simple COUNT in subquery, the answer was "give up and just use Arel." But at this point it is no longer quite Act…

That's really easy. Post.select("posts.*, count(comments.*) as comments_count").joins(:comments)

That is not the same query at all. You need to do a left join and a group by for it to become the same query. Wihout a left join posts without comments wont show up in the result.

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

#234

Post by collyw »

stana wrote: post #163

One important benefit of using an ORM is not being locked in with a particular DB server tech. Good luck migrating large app not using ORM, from, say, MySQL to Postgres if, for example, Postgres replication is something you are all of sudden interested in.

Has anyone ever actually migrated a database on a non trivial application? I want to go from MySQl to Postgres, but I am not sure if its worth the risk / effort. We got told about the standard nature of SQL in University, and how you could swap engines 'easily'. Then we started using them in real life and the reality of that situation hit.

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

#235

Post by lmm »

z92 wrote: post #195
EGreg wrote: post #182

Earlier quoted context omitted.

ORMs let you structure your queries in a way that allows the app to understand them and analyze them, for sharding purposes. True, you can write SQL and then parse it yourself in a proxy, but why?

If your ORM allows you to drop down to SQL, which the parent claims all modern ORMs do, then you will still need that SQL parser in your ORM.

Sure. So you can use the SQL parser from a mature, widely used library, or you can write your own. I know which option I would prefer, even if I was writing every single query by hand (not that I'd ever do that).

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

#236

Post by gedrap »

toast0 wrote: post #121
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…

> 2. If you're not using an ORM, then you ultimately end up writing one. And doing a far worse job than the people who focus on that for a living. It's no different from people who "don't need a web framework", and then go on to re-implement half of Rails or Spring (without accounting for any CSRF protection). Learning any framework at a professional level is a serious time investment, and many student beginners or q…

In some cases you are right. If all you need is a simple landing page, with a simple form or two, then by all means - do it.

However, if your application is more complex, you should be careful. Chances are, you will add your own layers. And chances are, they will suck more than some popular framework or ORM. It's not that you make a conscious decision, a plan to do so, usually it's bit by bit. And having seen all the custom frameworks and shitty ORMs (because it seemed easier at some point early in the project), don't write your own ORMs for the sake of the maintainers mental health if not your own.

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

#237

Post by khorpy »

collyw wrote: post #231
khorpy wrote: post #220

When considering using ORM we need to answer simple questions: does it help to decrease code size? In most cases ORM code is same size as SQL query. Secondly, does it hide complexity? No, it just adds up one more layer that in fact increases complexity and makes it harder to debug. Finally, does it protect us from errors or impoves code quality? This is rarely the case. Instead of using ORM I prefer moving data retri…

In most cases its smaller (in the Django ORM anyway). myobject, created = MyObject.objects.get_or_create(field1='1' , field2=field2) That would take a number of lines. One query to check if the object exists, another to create it / retrieve it, plus application code to deal with that SQL.

Ok, for this particular example, is operation wrapped in transaction? How will code evalute if we need to check some condition on field2 and occasionally update it?

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

#238

Post by _pmf_ »

gregopet wrote: post #42

I've come to love jOOQ, the Java library that I can write type-safe pure SQL in (and with code that is immediately understandable to anyone who knows SQL). It provides mechanisms to smooth the clash of Java/SQL worlds, but otherwise never assumes it is smarter than the wisdom accumulated through decades of database usage. I've come to appreciate many aspects of databases again that tools like Hibernate try to hide fr…

I was intrigued by jOOQ, but the huge amount of generated code for internal metadata of the DB was a bit offputting. I don't want 4MB of generated classes for 3 very small tables.

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

#240

Post by lmm »

kerkeslager wrote: post #136
manigandham wrote: post #129

Earlier quoted context omitted.

> A lot of things people use ORMs for are rather easily solved with stored procedures More like 1 thing. ORMs are meant to make interfacing through the object/relational impedance mismatch easier and through the regular code in your application. Stored procedures do not come anywhere close to this and are usually the same as just calling any other SQL query as you would when not using an ORM. If you think any majorit…

I agree with this, but I'd also add that if your ORM is doing a lot beyond the capabilities of your database, it's an indicator of a hacky design in your application. If there's a large object/relational impedance mismatch, then either the objects or the relational DB are a poor fit for the problem you're trying to solve, and an ORM can't really fix that. If your ORM is just providing a mapping between select/map, wh…

I think when people talk about using an ORM or not they're mostly talking about using a LINQ-like wrapper or not. There's maybe a conversation to be had about some kind of fancier features on top of your ORM and whether they're worth it, but I don't think those kind of features are what people usually mean when they talk about ORMs (whether they're technically what the acronym "should" mean or not).
Post reply on HN