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)

woz.posthaven.com

Post reply on HN
Print view View original

161–170 of 360 posts

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

#161

Post by rickycook »

bmarkovic wrote: post #159

It's "Active Record" style ORMs like Hibernate that are the culprit, and the way many developers utilize them to avoid any contact with the realities of RDBMs which leads to data access antipatterns which lead to poor performance (multiple needless queries per request etc.). Another thing people need to really give up on is the pipe dream of switching databases -- you're not going to do it. I've never seen one single…

i’d agree switching a current project from DB server to a different on is a pipe dtream, but the couple of use cases that are related but incredibly handy are switching DB driver mid project for any number of reasons, or using a new and unfamiliar database in a new project

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

#162

Post by zkomp »

0xCMP wrote: post #35
wasted_intel wrote: post #25

Earlier quoted context omitted.

Keeping logic in the database like that means you can’t version those procedures alongside the rest of your code. That’s a pretty big downside.

I mean you could, but it’d need to be through some kind of migration system to update it.

There are several such tools, which are specialized and thus tend to perform a better job than orms (who try to do everything)

But I would recommend writing, reviewing and deploying migrations by hand, esp for critical parts of the schema (automatic tools are almost guaranteed to get something wrong, with locking etc)

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

#163

Post by zkomp »

blaisio wrote: post #151
zkomp wrote: post #133

Earlier quoted context omitted.

No. You should really wind up with a DAL. Define some stored procedures for accessing and working on the data and use only stored procedures. No need for ORM, and no inline sql logic in your application code.

I mean, stored procedures are fine, but I don't think that actually solves anything? Except maybe for reducing the amount of SQL code you have to send back and forth and (in some databases) allowing for a few more optimizations? If you use stored procedures, all you've done is move part of the model into the database, so you have to update the stored procedures as part of a deployment. You still need to have the SQL…

you solved isolation decoupled much of the db logic from app-logic and made security easier

you can deploy schema changes independently

you can change everything and the app should not notice

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

#164

Post by stouset »

failedxyz wrote: post #127
JamesBarney wrote: post #120

Earlier quoted context omitted.

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

But that's a completely orthogonal problem — the point made (way) above is that you need to understand SQL whether or not you use an ORM.

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

#165

Post by gjjrfcbugxbhf »

failedxyz wrote: post #127
JamesBarney wrote: post #120

Earlier quoted context omitted.

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

Most ORMs have way too write raw SQL. Furthermore someone using an ORM well will understand how their queries are mapping to SQL.

Your scenario happens with people that either don't know or don't care. They will write crappy queries with any tool.

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

#166

Post by dang »

jeswin wrote: 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…

Thanks for the year! Missed that before. Added now.

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

#168

Post by bpanon »

erikpukinskis wrote: post #79
zzzeek wrote: 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…

Ok, let’s break this down: > Good ORMs are there to automate the repetitive tasks of composing largely boilerplate DML statements, facilitating query composition, providing abstraction for database-specific and driver-specific quirks None of that requires an ORM. A simple query builder will suffice and it will be much easier to debug and much less error prone than an ORM. > providing patterns to map object graphs to…

No, no, no, I know more than you.

Here is why.

Bitcoin cryptocurrency AI biomedical supply chain networking quantum systems-thinker.

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

#169

Post by groue »

There are ORMs that address partial records, multi-threading troubles brought by lazy loading, uniquing, auto-updating records, and, importantly, put raw SQL on the same level as the query builder. I think of [Diesel](http://diesel.rs) and [GRDB.swift](https://github.com/groue/GRDB.swift/blob/master/Documentatio...).

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

#170

Post by pmontra »

JamesBarney wrote: post #123
alexandercrohde wrote: post #61

Earlier quoted context omitted.

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.

+1 for these three points.

But I'm really surprised every time people tell me they look at the schema as defined into the ORM instead of at the table in the database.

I'm really jaw dropped the few times I know somebody doesn't even know SQL, only the ORM. Maybe they look at it as if it were the reaction of somebody that thinks you must know assembly if you want to program Ruby, Python or Node (I don't.) Still, if you work with a database you must know it's internal language, SQL or NoSQL. Your going to need it or build a mess.

And involving a DBA early in the project can make your database at least twice as fast, with the right schema and the right queries. Then you translate that into the ORM you want to use.

Post reply on HN