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

201–210 of 354 posts

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

#201

Post by BlackFly »

setr wrote: post #176
nodamage wrote: post #174

People have been making these same arguments for decades and at this point I'm convinced they are all based on the same strawman: That ORM's absolve you from having to learn SQL. Once you understand that was never actually true to begin with you can treat the ORM as a tool that simply helps you generate repetitive boilerplate queries and hydrates result rows back into objects for you. Furthermore, if your objects are…

The problem with ORMs are 1. They pretend SQL is standardized, and support a heavily reduced featureset for any given database as a result 2. They leave awkward holes in their abstraction, leading to psychotic behaviors like N+1 and implicit type coercions to helpfully break your indexes silently 3. They make simple queries simple, and hard queries absolutely revolting 4. You end up not wanting to use the objects dir…

I agree completely, the features the parent is mentioning like "identity mapping, unit of work, and change tracking/events" are exactly the things I don't want out of the ORM because that is the leaky abstraction I don't want to constantly be working with and around.

If it was just a query builder we could have a conversation about the benefits of that vs sql and when one beats another. But it is all kinds of other features that are implicitly activated and then conspire to ruin your day when you were trying to solve some other problem. ORMs bring too much baggage by default. So now you have to talk about its relative merits compared to just writing SQL and the merits of always having these other features activated. Which other features? You need to read your full ORM manual because they really vary from one to another.

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

#202

Post by nodamage »

setr wrote: post #176
nodamage wrote: post #174

People have been making these same arguments for decades and at this point I'm convinced they are all based on the same strawman: That ORM's absolve you from having to learn SQL. Once you understand that was never actually true to begin with you can treat the ORM as a tool that simply helps you generate repetitive boilerplate queries and hydrates result rows back into objects for you. Furthermore, if your objects are…

The problem with ORMs are 1. They pretend SQL is standardized, and support a heavily reduced featureset for any given database as a result 2. They leave awkward holes in their abstraction, leading to psychotic behaviors like N+1 and implicit type coercions to helpfully break your indexes silently 3. They make simple queries simple, and hard queries absolutely revolting 4. You end up not wanting to use the objects dir…

Which ORMs are you basing this comment on exactly?

(1) and (3) are not really problems with an ORM that gets out of your way and lets you drop down to raw SQL when necessary, but still helps you hydrate result rows back to objects (and still provides the associated features I mentioned previously).

(2) and (5) can be interpreted as "your ORM does not absolve you from knowing SQL".

I've never personally run into a situation where doing (4) or (6) were desirable.

> The correct answer is to use a query builder + database model, enabling most queries to be written with some degree of type-safety, and minimizing the abstraction from SQL itself, and toss out the rest of the featureset

If you work on projects where a full featured ORM can be replaced by a simple query builder then cool, but the rest of the feature set is really useful for the projects I work on so why would I toss them out?

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

#203

Post by MayeulC »

therealdrag0 wrote: post #197
bluefirebrand wrote: post #149

Earlier quoted context omitted.

> different levels of sophistication Most of those are not necessary for 90% of use cases I'm not taking the piss either All most people really need to know is table CRUD, row CRUD, and a bit about indices. For anything more advanced you'll need a DBA, but IMO you unless you are scaling like crazy you will not need much more than that for SQL knowledge. It's really, really not that complex for most use cases

You should also learn joins and ordering/pagination. But that can be on day 2 :)

[dead]

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

#204

Post by nodamage »

BlackFly wrote: post #201
setr wrote: post #176

Earlier quoted context omitted.

The problem with ORMs are 1. They pretend SQL is standardized, and support a heavily reduced featureset for any given database as a result 2. They leave awkward holes in their abstraction, leading to psychotic behaviors like N+1 and implicit type coercions to helpfully break your indexes silently 3. They make simple queries simple, and hard queries absolutely revolting 4. You end up not wanting to use the objects dir…

I agree completely, the features the parent is mentioning like "identity mapping, unit of work, and change tracking/events" are exactly the things I don't want out of the ORM because that is the leaky abstraction I don't want to constantly be working with and around. If it was just a query builder we could have a conversation about the benefits of that vs sql and when one beats another. But it is all kinds of other f…

Your comment comes across like saying "why would I use an impact driver when my screwdriver does everything I need?"

If you don't actually need those features then obviously an ORM will offer less value to you. That doesn't mean ORMs aren't useful tools, they just aren't useful for the problems you work on.

I tend to work on projects where those features are useful and if the ORM didn't provide them out of the box then I would need to build them myself. In other words using a query builder alone does not adequately solve the problems I need to solve.

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

#205

Post by ako »

dadie wrote: post #18
valzam wrote: post #7

The big problem is that raw SQL has pretty bad type inference and linting support in most editors. A query builder can still give you a lot of type safety benefits.

I think the bigger problem is that SQL is in almost every language a second-class citizen. And even calling it second-class can be seen as a stretch.

Time to start using plsql, ADA with first class support for embedded SQL.

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

#206

Post by delusional »

ElectricalUnion wrote: post #150
sandreas wrote: post #106

Earlier quoted context omitted.

Additionally I think the migration management that most ORMs support are also a good thing. Defined and type-safe forward and backward strategies are helpful in most cases, especially if you'd like to support more than one DBMS. I personally think that ORMs are good for management and simple CRUD cases, QueryBuilders are good for managing more complex queries while still being secure / type-safe and for everything el…

> ORMs are good for management and simple CRUD cases I for one think that "simple CRUD cases" is bullshit, those applications don't exist. In practice, System-of-Records systems are rare. (and should be, their value are inversely proportional of how many of those you have in your overall system). Because if it was "just simple CRUD", one would use the database directly? Databases are already capable of handling CRUD…

As my career progresses, I'm starting to understand just how many developers have trouble comprehending invariants and how they affect system design. If you do not comprehend invariants, then every system is CRUD.

The specific danger of CRUD is that all operations are expressible in it. If your system is CRUD, everything goes. A developer who doesn't understand the system's design might be inclined to assume an application is "just CRUD" and add all sorts of misfeatures to it that violate otherwise constrained states. They will turn the application into CRUD.

All it takes for an application to go from carefully modeled to CRUD is for people to believe it already was just CRUD.

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

#207

Post by globular-toast »

noisy_boy wrote: post #8

As someone who started their programming journey with SQL, it just feels so odd hearing about learning SQL being presented as an useful option. I get it, it just feels odd. SQL was considered table stakes in the financial IT world - if you said you didn't know SQL, people would look at you funny.

I was working with a "full stack" engineer and needed to do some ad hoc data manipulation so I wrote some SQL inserts and updates. He was like "whoa, I didn't know you could do that with SQL!" I was shocked. Like, how have you been working on projects using databases this long without knowing basic SQL? I still don't think they know about DDL at all.

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

#208

Post by globular-toast »

robertclaus wrote: post #95

There are simple "ORM"s that just map classes to tables and columns to attributes. Basically focused on serialization instead of query generation. I find those to be a good balance.

Yeah, you can use SQLAlchemy like this. It's called the data mapper pattern. The bad type is like Django or Rails "Active Record" type ORMs.

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

#209

Post by Mikhail_Edoshin »

miohtama wrote: post #199
tengbretson wrote: post #100

I don't disagree with any of the major gripes people have with orms and I find SQL to be much cleaner in a lot of circumstances. That being said, if orms didn't force you to explicitly define your domain models about 60% of developers would simply never do it. And you would see differently structured, ad-hoc interfaces defined all over the code base completely entangled with whatever action they are trying to perform…

SQL is pretty shitty language to write modular, reusable and easy to read code.

It solves a hard problem. For example, it completely insulates the sender from the fact that his transaction is just one among many others.

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

#210

Post by xigoi »

ambicapter wrote: post #83
dadie wrote: post #18

Earlier quoted context omitted.

I think the bigger problem is that SQL is in almost every language a second-class citizen. And even calling it second-class can be seen as a stretch.

I’m a SQL-lover and ORM-hater but I don’t see why any language would support another wholly different language as a first-class citizen.

Ideally, SQL wouldn’t be a wholly different language, but a library with bindings for various languages.
Post reply on HN