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

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

#201

Post by zwischenzug »

zepolen wrote: post #37
fishtoaster wrote: post #31

Earlier quoted context omitted.

I completely agree. 90% of the queries in my app are no more complex than selecting from a table with a simple condition. I definitely find users = User.where(has_foo: true).limit(10) to be a lot more readable than rows = connection.exec_query("SELECT * FROM users WHERE has_foo=true LIMIT 10") users = rows.map { |row| User.build(row) } (And that's an example with no user-provided input) Likewise, any app of sufficien…

Here's the thing, anyone who knows SQL will find the second one readable, and only Ruby programmers who have used ActiveRecord will know how the first one does.

Not true. They're both readable, but trying to do anything more interesting becomes painful, and this is where having a common tool for the job helps.

It's like regexps - imagine if there were 30-40 different implementations instead of 2 or 3.

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

#202

Post by nodamage »

notyourwork wrote: post #191
nodamage wrote: post #187

Just once I'd like to see someone write an opinion about ORMs without resorting to sweeping generalizations ("Vietnam of computer science") or making assumptions about how they are being used ("it wasn't a good fit for my use case so therefore it must never be"). Maybe, just maybe, it's possible that ORMs are useful for solving certain types of problems and less suitable for other types. If you work on web stuff or a…

Is this not the general sentiment of any piece of software? It was implemented to serve a purpose, if that purpose is not sufficing a goal of yours it is not relevant to you.

Indeed. It would be nice though, if people, having realized that a particular tool isn't useful for their particular goals, could still acknowledge that it could be useful in other situations, instead of blaming the tool itself.

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

#203

Post by lmm »

bunderbunder wrote: post #172
Bahamut wrote: post #141

Earlier quoted context omitted.

I'm currently at a company that is not using an ORM - what has happened is that developers have written endpoints with inconsistent data formatting for similar data types, which prevents the possibility of creating abstractions cleanly on the client. It would have been nice to have a lightweight ORM, if only for object consistency.

I've been at companies that did use ORMs, and still ended up with that kind of mess. No tool is ever a substitute for discipline.

> No tool is ever a substitute for discipline.

My experience is exactly the opposite. Humans are too fallible for discipline to ever be reliable. If you want something done, automate it.

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

#204

Post by collyw »

elcritch wrote: post #154
prodigal_erik wrote: post #25

Earlier quoted context omitted.

We have decades of research into filtering, joining, and aggregating across a complex set of tables and views. With microservices you have to roll your own query planning and stream all the intermediate results on the wire even when you're throwing away most of them.

Unfortunately, SQL servers aren't generally scalable. Offloading joins and aggregation onto (inexpensive) app servers can increase over all system performance, despite lack of advanced query planning.

Bollocks. SQL scales fine unless you are stupid in the way you use it. All the crap performance I have seen in the last couple of years have been from doing crap like you suggest - doing joins and aggregation at the application level. Our front page currently makes over 1000 database calls because of this sort of nonsense.

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

#205

Post by lmm »

teacup50 wrote: post #65
StevePerkins wrote: post #34

Ten years ago, there was a blog post every other week bemoaning ORM's. Ten years ago, those posts often had merit. In 2016, this sentiment is outdated. A few points: 1. If you think that using an ORM means you don't have to learn SQL, then you're going to have a bad time. This is where most of the bad press originates... from people who never really learned SQL or their chosen ORM. An ORM provides type checking at yo…

> If you're not using an ORM, then you ultimately end up writing one. Only if you assume that Object Relational Mapping is the only way to express type checked database access at the application layer. ORMs are broken by design; there's no lossless bridge between relational theory and OO -- only inconsistent, error-prone, complex approximations. Instead of bringing relational theory to the programming language, ORMs…

More like relational databases are outdated. There was one truly committed effort to bring the database model into the programming language - EJB - and there's a reason it's now a curse word. The successful systems of the past ten years have been those that moved away from the relational model, using simple datastores controlled by application code.

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

#206

Post by lmm »

maxxxxx wrote: post #75
nickpeterson wrote: post #44

Earlier quoted context omitted.

Also Java and C# developers often produce bad SQL procedures because they tend to think procedurally about problems.

I think if they were better integrated with the IDE and easier to debug then they would probably write better stored procedures.

And easier to unit-test, and profile, and had a better standard library available, and...

SQL is a terrible general-purpose programming language by the standards of today, which makes it a terrible way to express business logic.

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

#207

Post by lmm »

beachy wrote: post #32
vrdabomb5717 wrote: post #13

Earlier quoted context omitted.

At the big tech firm I work at, there's a best practice where any database (whether that's a traditional RDBMS or a NoSQL client) is abstracted away by a microservice with a defined API, and every other application that wants to get that data needs to interact with the microservice. That way, the database schema can change without it affecting multiple applications. There's still the traditional mismatch between ORM…

That kind of sounds like a microservices anti-pattern in disguise. Its thought by many to be bad practice for microservices to share a common database. But that's pretty much what you're doing, but just with an API instead of jdbc for the access.

An API is much easier to version-control, automatically check for compatibility and so on.

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

#208

Post by spacecowboy_lon »

Udik wrote: post #115
platz wrote: post #76

Earlier quoted context omitted.

What is the source of the wariness?

Don't know about the parent, but I always felt that stored procedures end up by incorporating a good share of the business logic, extracting it from the main code of the application. This creates a messy situation in which you have your business logic split up between two completely separate and different systems, one of which (the stored procedures) is much harder to read, write, maintain and test. That said, I also…

That is normally considered a good thing other wise different applications accessing the same data have to roll there own - do you really want multiple versions of biz logic.

eg a large organizations like a bit telco may have multiple applications that update customer records.

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

#209

Post by spacecowboy_lon »

gozur88 wrote: post #116
teacup50 wrote: post #65

Earlier quoted context omitted.

> If you're not using an ORM, then you ultimately end up writing one. Only if you assume that Object Relational Mapping is the only way to express type checked database access at the application layer. ORMs are broken by design; there's no lossless bridge between relational theory and OO -- only inconsistent, error-prone, complex approximations. Instead of bringing relational theory to the programming language, ORMs…

This. Ye Gods, this. A project with nontrivial data relationships should start with the data model, not with a code model superimposed on data. ORM leads to bad data models and performance problems that are unfixable.

testify Brother/Sister Testify

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

#210

Post by lmm »

prodigal_erik wrote: post #25
vrdabomb5717 wrote: post #13

Earlier quoted context omitted.

At the big tech firm I work at, there's a best practice where any database (whether that's a traditional RDBMS or a NoSQL client) is abstracted away by a microservice with a defined API, and every other application that wants to get that data needs to interact with the microservice. That way, the database schema can change without it affecting multiple applications. There's still the traditional mismatch between ORM…

We have decades of research into filtering, joining, and aggregating across a complex set of tables and views. With microservices you have to roll your own query planning and stream all the intermediate results on the wire even when you're throwing away most of them.

The thing is, letting the system handle it isn't good enough. We have decades of research into this stuff, so 90% of the time the database gets it right - but the interface for explicitly taking control when the DB gets it wrong is black magic at best. The value of having an exposed representation of filtering/joining/aggregation in a general-purpose programming language where you can interact with it is big enough to outweigh that of a database that can do it for you most of the time.
Post reply on HN