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 654 posts

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

#231

Post by ratww »

jkdufair wrote: post #183

I would have generally agreed with this sentiment until we took a leap of faith and chose Entity Framework 4-5 years ago. That, coupled with the power of LINQ has allowed us to do things we simply wouldn’t be able to do otherwise. Pass IQueryables around without realizing them right away. This leads to functional, composable queries. And the queries we generate would simply not be possible to be written by hand. If w…

Entity Framework and LINQ are amazing feats of engineering.

Its query builder is super transparent, consistent and flexible, thanks to LINQ, but still generates very performant queries.

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

#232

Post by otakucode »

In my prior job, I worked with a few (really skilled) interns that were just finishing up their CS degrees. I found out that they didn't learn any SQL at all and their interactions with databases was severely limited overall. This really surprised me, as I had a whole databases course when I went through college (different school, but in the same state, just 20 years earlier). Is not teaching SQL or relational database concepts no longer common at colleges? I should mention that the school they went to otherwise was excellent and taught a great many things my own schooling never touched on and I had to pick them up later myself. I'm just curious if it's a matter of just that school, or if other courses have been prioritized across the academic field generally for some reason.

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

#233

Post by sjwright »

stickfigure wrote: post #208

Beginning programmer: ORMs let me write code without learning SQL! Intermediate programmer: ORMs just get in the way! SQL isn't that hard after all. Advanced programmer: I write a lot of SQL, but I use ORMs to cut out most of the boilerplate.

Even more advanced programmer: writing the ‘boilerplate’ queries out manually takes barely more time than composing them in an ORM, means less indirection, saves me a major dependency, and encourages me to think intelligently about each query no matter how boilerplate they might seem at the surface.

Super-advanced programmer: allowing my database structure to be influenced by the needs of an off-the-shelf ORM will make it worse.

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

#234

Post by mumblemumble »

725686 wrote: post #37

Each time I see someone complain about ORMs I remember Greenspun's tenth rule[1], which adapted to ORM would be: "Any sufficiently complicated program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a decent ORM." ORMs are hard for a reason. Using an ORM doesn't mean you can't or shouldn't use plain SQL where the situation calls for it. You can mix and match perfectly fine. [1] ht…

I think that this is true if you're writing your application in a way that requires object-relational mapping in the first place.

And that's only necessary when you're trying to manage your data in the application in an object-oriented way. And managing your data in an object-oriented way implies more than just the simple fact of defining classes to serve as data records. Those classes can be entirely equivalent to a struct in a procedural language or a record in a functional one. And I can't remember ever suffering from object/relational impedance mismatch when working in a procedural or functional language. Implying that the spot where you really start getting into trouble is when you trot out some distinctive feature of an object-oriented data model.

I submit that the original sin is treating instances of those data classes as if they are discrete entities that can serve as an application-side proxy for some other discrete entity that exists in the database, almost as if ODBC were just a more REST-flavored alternative to CORBA. Which is a thing that I've often been tempted to do in an object-oriented language, but never in a procedural or functional one.

Which isn't to say that I don't use anything to help with talking to databases in those other styles of language. It's just that I retain SQL as my query language (there are plenty of reasons to do it, none of which I'll bother to repeat here) and rely on a more Dapper-style library to handle unpacking the results into data structures. And I don't really consider those to be ORMs; they're just a special class of data mapping utility library.

So, in conclusion, I think that a more accurate stab would be "Any sufficiently hastily built, object-oriented, database-driven non-ORM program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a decent ORM."

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

#235

Post by pjungwir »

stickfigure wrote: post #208

Beginning programmer: ORMs let me write code without learning SQL! Intermediate programmer: ORMs just get in the way! SQL isn't that hard after all. Advanced programmer: I write a lot of SQL, but I use ORMs to cut out most of the boilerplate.

That's pretty much exactly how I feel. I gave a talk a few years ago about doing advanced SQL things in ActiveRecord [0]. The talk suffered I think from lacking a unifying idea and because I tried to offer something to the whole spectrum of experience (from "this is a join" to "this is how you can express a CTE/lateral join/window function in AR"), but the real unifying motivation/message was that with AR you can have your cake and eat it too.

I've approached tons of problems by making it work in SQL first and then translating it into AR afterwards (to some degree or other). I would reject an ORM without an "escape hatch", but AR is wonderful for taking away the boilerplate while still letting you write SQL when you need it, and even letting you make SQL more composable by defining scopes.

I'm just wrapping up a couple C# projects where everything is direct SQL, and oh man is it verbose and painstaking! Every day I long for more Rails work. :-)

[0] https://github.com/pjungwir/rails-and-sql-talk

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

#236

Post by tomtomtom777 »

725686 wrote: post #37

Each time I see someone complain about ORMs I remember Greenspun's tenth rule[1], which adapted to ORM would be: "Any sufficiently complicated program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a decent ORM." ORMs are hard for a reason. Using an ORM doesn't mean you can't or shouldn't use plain SQL where the situation calls for it. You can mix and match perfectly fine. [1] ht…

What you are saying exactly highlights what the author is missing: That if your application has some logic, you will eventually have to map your database rows to your in memory typed structures.

It sucks. Sometimes it sucks less if you map your queries as well, sometimes it sucks less if you stick to SQL and only map your results, sometimes it sucks so much you're better off with a no-sql solution.

But when using a relational database, ORM isn't optional.

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

#237

Post by _bxg1 »

Daishiman wrote: post #218
_bxg1 wrote: post #166

In my opinion this whole problem is one of the strongest condemnations of OOP. Even if OOP really were a great way to model your data, to express relationships and property types and such (setting aside all the questionability of that claim), it's all just going to end up in a database anyway . Unless you're using a denormalized database like Mongo, or the bulk of your application state is non-persistent, your perfec…

What makes you think that the DB will always by the dominant data store for a business object? Business objects need a lot more, from rendering, processing, email sending, notifications, etc. All those things are well approximated by an object and poorly approximated by SQL.

Everything you can build with OOP can be done with FP and vice-versa. So the question is which one's strengths you'll most benefit from.

OOP's strengths surround modeling nested object structures and encapsulating state and logic within opaque containers. If you're primarily writing data to/reading data from a relational database, everything gets flattened and exposed. So you have to ask yourself what you're getting from it at that point.

Rendering and processing are well-suited to FP. "Email sending" and "notifications" are vague, but I see nothing about SQL + FP that makes those harder.

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

#238

Post by stephen82 »

JesseAldridge wrote: post #227

This was my position for a while. ORMs introduce a layer of magic which obscures what's actually going on under the hood. I decided I would just make raw SQL queries and handle mapping data explicitly. I quickly ended up with a lot of duplicated code. So then I thought, "Well ok, I should add a bit of abstraction on top of this..." I started coding some simple functions to help map the tabular data to objects. One th…

Hahaha! ^_^

Seriously Jesse, isn't this the very same reason __some__ people end up implementing yet another programming language without realizing it?

First they start out of exasperation with X language they use, because they hit some obstacles or limitations, and before they know it they end up implementing a newly created language.

You know what's the fun part? In their attempt to fix the aforementioned language's issues, they end up introducing __the very same problems__ in their own language, only under different "cloak" so to speak.

It's a vicious cycle I'm afraid...

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

#239

Post by [deleted] »

sjwright wrote: post #233
stickfigure wrote: post #208

Beginning programmer: ORMs let me write code without learning SQL! Intermediate programmer: ORMs just get in the way! SQL isn't that hard after all. Advanced programmer: I write a lot of SQL, but I use ORMs to cut out most of the boilerplate.

Even more advanced programmer: writing the ‘boilerplate’ queries out manually takes barely more time than composing them in an ORM, means less indirection, saves me a major dependency, and encourages me to think intelligently about each query no matter how boilerplate they might seem at the surface. Super-advanced programmer: allowing my database structure to be influenced by the needs of an off-the-shelf ORM will ma…

[deleted]

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

#240

Post by hardwaresofton »

ORMs are a leaky abstraction -- there is a sweet spot (mostly basic queries/relationships) where they provide lots of value, but there is a veritable infinity of scenarios beyond where they are a hindrance. Also they tend to introduce lots of hidden complexity when they try to introduce flexibility to match the landscape.

I'd argue that most of the time what you really need is a query builder with the right combinators, and maybe some higher order combinators to wrap those together for even better ergonomics.

For those writing NodeJS one of the best ORMs that I've found is typeorm[0], check it out.

Here are some reasons I like it:

- Typescript-first

- Provides the repository pattern (ex. repository.findOne) & the entity manager pattern (ex. manager.findOne) so you can use whichever you prefer

- Annotation-based entity markup

- Ability to drop down to raw SQL query easily at any time

- Query building ability, special handling for relation queries, it's even got support for building with where params like and and or

- Great documentation

- Ability to programmatically use the introspection that it does for you (accessing the metadata from code is trivial)

- Handles migrations (you can generate them, run them, etc), easy to use programmatically as well

- Supports some low level concepts from my own favorite RDBMS, postgres

[0]: https://github.com/typeorm/typeorm

Post reply on HN