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

201–210 of 360 posts

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

#201

Post by ux-app »

fuck ORMs. Here's the thing, the DB queries will make up less than 0.1% of your typical codebase. Spend a week and write a good fucking query instead of relying on your bullshit magic blackbox to do it for you. Even a shitty query is going to perform better than the 100s or (literally!!) 1000s of lines of ORM code which need to happen to generate your "select * from users" query.

seriously. grow up. learn the amount of SQL you need to and napalm any ORM that comes within arm's reach.

and if you're not sure about the SQL you've come up with then just go a few cubicles down and ask your DBA what they think. Chances are they'll write something 1000x better than you came up with an you'll have learned something along the way. win-win.

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

#202

Post by scarface74 »

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…

So the easiest way to avoid using an ORM is to create your own ORM?

What AI do you need? You map your tables to objects and relationships between objects via FK relationships.

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

#203

Post by flavio81 »

andrewstuart wrote: post #93
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…

zzzeek - can I take this chance to praise your work on SqlAlchemy. People say there's not enough thanks given to open source developers... here's thanks to you. It's the work of a craftsman.

+1 SQLAlechemy is an excellent library. Zzzeek, many kind thanks for such a good ORM.

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

#204

Post by scarface74 »

majewsky wrote: post #183
Animats wrote: post #175

Earlier quoted context omitted.

ORMs are more useful as insert builders. Putting data from an object into the database is something of a boilerplate process. Queries vary with what you want to ask. Most of the time, you don't need all the fields, so filling up some object just because it has slots for everything is a waste of effort. Especially if it means references to multiple tables.

I think the best ORMs are those that just leave out the "Relational" part entirely. So... "OM"? For example, in Go, I use Gorp, which has a Select() function where you pass in the SELECT query string (plus bound values) and the target type, and it loads every result row into an object of that type. So you can have an arbitrarily complex SQL query as long as it starts with `SELECT one_table.* FROM`. That's a marvelous…

Why is it an either or? EF can do that but then you loose the benefits of a type safe language.

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

#205

Post by gldalmaso »

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.

I find that jOOQ (java) solves all that for me.

Very happy to not have and ORM on our stack for many years.

I believe that the interaction with the database is just about the most important part of code that you need to rely on. We have had messy data written to the database due to misused or misconfigured ORM (perfomance issues, bad orphan handling, session state problems, overflown sequences, to list a few) and decided that we should not rely on all devs touching that code to be experts in the ORM api to avoid the pitfalls, we rather our devs be expert in SQL.

Never had any of them complain about mapping using something like jOOQ. Type checking and composability are also built in.

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

#206

Post by scarface74 »

zimpenfish wrote: post #188
petre wrote: post #176

Earlier quoted context omitted.

A query builder aids you at constructing queries, while an ORM builds queries for you, runs them and maps the output to objects. It's more sophisticated than a query builder.

> A query builder aids you at constructing queries ... that you understand and can be sure are sensible. > while an ORM builds queries for you ... that you have to hope are sensible. That's one of the biggest flaws of the ORM for me - you have limited visibility of what it's doing to your DB.

How so? I can log the the sql being generated and look at the logs. Something I should be doing either way.

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

#207

Post by [deleted] »

eru wrote: post #70
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…

Is LINQ actually an ORM? It looks like a DSL to do relational stuff in C#, but I don't see where the 'O' part of ORM fits in especially not in your examples to show off LINQ's power and convenience.

[deleted]

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

#208

Post by scarface74 »

Merad wrote: post #96
eru wrote: post #70

Earlier quoted context omitted.

Is LINQ actually an ORM? It looks like a DSL to do relational stuff in C#, but I don't see where the 'O' part of ORM fits in especially not in your examples to show off LINQ's power and convenience.

LINQ itself doesn't have anything directly to do with SQL. It's a mechanism for composing expression trees that are compiled into your application. At runtime a LINQ query provider can walk the expression tree and translate it into a query for the underlying data store. It's a very very powerful concept, but IME it doesn't get used all that much for things other than SQL because writing a query provider is a lot of w…

The Mongo Linq provider is excellent.

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

#209

Post by scarface74 »

zkomp wrote: post #133
blaisio wrote: post #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…

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.

Just use stored procedures? Then you lose the ability to do unit testing without a database dependency, it's a lot easier to rollback code than to rollback code and stored procedures as one and you don't get full visibility on what the code is doing just by looking at the source code.

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

#210

Post by scarface74 »

zkomp wrote: post #163
blaisio wrote: post #151

Earlier quoted context omitted.

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

Why would you want to deploy schema changes separately? I would be horrified if someone changed my DB back end without running a full (hopefully automated) set of tests.
Post reply on HN