What ORMs have taught me: just learn SQL (2014) • Hacker News Board

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

#381

Post by revscat » Sat, Sep 21, 2019, 3:27 AM UTC

delusional wrote: post #157

yawaramin wrote: post #99

Earlier quoted context omitted.

> ORMs are hard for a reason. Yes, the object-relational impedance mismatch. It's the classic case of having a hammer (OOP) and trying to make everything look like a nail.

I would actually let OOP off the hook here. I think what did the harm in this case was the java generation. The generation of programmers that were told that in the future they would only have to write the "business logic", and everthing else would just happen. They were taught javabeans, orms, gigantic frameworks. They completely forgot that their code actually needed to execute, and no one cared about their "busine…

This is the polar opposite of my experience. Not to mention that you undercut your own argument by admitting SQL’s tediousness: tedious code tends to lead to more tedious code, as subsequent developers fear breaking something, so they just add a layer on top of it, rather than addressing root causes. So that SQL view you had now has 10 inner joins in it, a union, and is being used by five other views now, each with their own similar levels of complexity. Trying to do any refactoring on this is almost humanly impossible, because you can’t keep all of it in your head.

And this is an extremely common situation to find yourself in. Code bases which are of middle- to large-sized, and which are inevitably touched by various hands of various skill levels, tends towards complexity.

SQL is the worst source of unmaintainable and difficult to refactor code. It’s difficult to unit test. Error messages are more often than not inscrutable. (I’m looking at you, Oracle.) There is no idiomatic way to break up complex SQL into functions or classes. There’s no type checking. You don’t have the equivalent of Ruby Gems, Python’s pip, or Swift’s CocoaPods. IDE support is limited to syntax highlighting Compare this with something like Eclipse or IntelliJ where you can just Ctrl-click on something and go to the definition. Want to rename a public method in a statically typed language? Pretty easy. Want to rename a column in SQL? Yeah, good luck. Not impossible, but you don’t have any guarantees that something won’t break until runtime.

So yeah. ORM has its place, and modern ones work very well at abstracting away SQL’s weaknesses.

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

#382

Post by toasterlovin » Sat, Sep 21, 2019, 3:28 AM UTC

FWIW, I think the sweet spot for most web apps is to use an ORM on top of database views. This gives you the power and performance of SQL, but avoids the impedance mismatch of the ORM, since you’re defining what data will be on your objects at the database level.

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

#383

Post by sjwright » Sat, Sep 21, 2019, 3:29 AM UTC

fastball wrote: post #284

sjwright wrote: post #233

Earlier quoted context omitted.

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…

What ORM do people use that influences the structure of their database? The ORM I'm currently using the most can do whatever I need with my Postgres DB. Also, the ORM allows me to specify models that are not only used for structuring the database, but also for validation of incoming JSON requests and easily serialize queries back to JSON.

ORMs that I've experimented with tend to fall into one of two categories: either they treat the object model as prime, or they treat the relational model as prime.

The former almost invariably spurt out inefficient queries, or too many queries, or both. They usually require you to let the ORM generate tables. If you just want to have your object oriented design persist in a database, that's great.

The latter almost invariably results in trying to reinvent the SQL syntax in a quasi-language-native, quasi-database-agnostic way. They almost never manage to replicate more than a quarter of the power of real SQL, and in order to do anything non-trivial (or have things done in a way that lets your database server scale) they force you to become an expert SQL anyway, PLUS an expert in how your ORM translates its own syntax into SQL.

And once you become more expert at SQL than your ORM, it's not long before you find the ORM is a net loss to productivity—in particular by how it encourages you to write too much data manipulation logic in code rather than directly in the database.

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

#384

Post by toasterlovin » Sat, Sep 21, 2019, 3:30 AM UTC

daenz wrote: post #14

ORMs lure you in with a false sense of neat abstraction. They have nice intuitive examples on their home pages. But then you use them in the real world, doing gnarly queries, and you realize that doing anything powerful and fast in the ORM requires its own completely separate abstractions, which are often difficult for the uninitiated to follow. It's also often a big pain to debug the raw SQL that gets compiled after…

If you have a gnarly query, encapsulate it in a database view and use an ORM to interact with that instead.

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

#385

Post by jwmoz » Sat, Sep 21, 2019, 3:30 AM UTC

Having to use Doctrine with Symfony and PHP was genuinely one of the main reasons I quit using PHP and went with Python.

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

#386

Post by pknopf » Sat, Sep 21, 2019, 3:33 AM UTC

ratww wrote: post #320

pknopf wrote: post #283

Earlier quoted context omitted.

> But Micro-ORMs are ORMs. Not in the traditional sense. > And yes, they do remove a lot of boilerplate. Here is all the "boiler plate" you'd need to use something like OrmLite with C#. https://pastebin.com/XUhQVPUk Type safety. No boiler plate. No abstractions. Errors are a result of the underlying data storage. This is where it's at. The sweet spot.

But I'm agreeing with you in all those points, like the sibling post said. I actually used OrmLite myself in some projects.

I see. Sorry.

high five

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

#387

Post by oefrha » Sat, Sep 21, 2019, 3:34 AM UTC

sjwright wrote: post #367

mst wrote: post #294

Earlier quoted context omitted.

If your ORM influences your database structure, either your ORM is shit or you don't know how to use it yet. ... or both. Both is always a possibility. Welcome to programming.

If the object reasoning inherent in ORM design isn’t influencing your structure, either your structures are trivial or you don’t know how to use the full capabilities of your engine yet. ... or both. Both is always a possibility. Welcome to databases.

Most perfectly viable database schemas in the real world are trivial by your definition of trivial. Trivial designs aren’t necessarily bad designs; sometimes quite the opposite.

Thanks for the condescension though.

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

#388

Post by wvenable » Sat, Sep 21, 2019, 3:41 AM UTC

celticmusic wrote: post #219

wvenable wrote: post #9

I use a data mapping ORM and I've literally not have any of these concerns. They are all non-issues. The first item about querying is relevant but all ORMs allow you to drop into SQL to execute a complex reporting-style query. It's not really necessary if you are just querying in objects to manipulate (which is what ORMs are good for).

A data mapper is not an ORM, it's a data mapper. It's a different access pattern. But I do agree that data mappers tend to be better.

https://medium.com/oceanize-geeks/the-active-record-and-data...

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

#389

Post by pknopf » Sat, Sep 21, 2019, 3:48 AM UTC

jtdev wrote: post #333

pknopf wrote: post #278

Earlier quoted context omitted.

> A sensible approach blends use of an ORM with handwritten SQL where needed. In fact most ORMs will allow you to do things like build collections of objects from custom SQL anyway, so there's really no need to shy away from it. This is really where it's at. Seriously people. Nobody should be writing raw SQL. Give me just enough of an ORM/abstraction to give me type-safety, leave the rest at the door.

> Nobody should be writing raw SQL. What?!? That’s an absolutely foolish and naive assertion. Please don’t give any of your fellow junior devs that “advice”...

Are you advocating that I put a bunch of magic strings in my codebase? That would be a maintenance nightmare.

Unless you think I'm suggesting that no devs should ever write SQL at all in their career? Which isn't the case.

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

#390

Post by zachrose » Sat, Sep 21, 2019, 3:49 AM UTC

kls wrote: post #375

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…

Out of curiosity what platform and tech where you using? I am making the assumption of a predominately OO one based on the virtues of ORM. I have always found that when I try to solution back end or middleware based platforms with OO dominate languages (read Java, C#, et. al.) that there quickly becomes an impedance mismatch and any communication with the database becomes a monster of mapping OO philosophy to relatio…

> I find the converse to be true for the front end. I find most attempts to deal with the UI in anything other than objects and components (read jQuery, React Hooks), turns to spaghetti rather quickly.

What alternatives have you tried?