News for hackers. Stuff that matters.

A comment on How not to structure database-backed web apps: performance bugs in the wild. Parent comment

Re:How not to structure database-backed web apps: performanc... by TekMol on Thursday June 28, 2018 @03:56AM (#17414927)
The ORM makes it more likely to do stuff in the application instead of the DB because many queries are hard or impossible to represent in an ORM fashion.

Additionally, the ORM makes it much harder to see what is going on under the hood. For example you don't know if a value of an object is stored in the main table or lazy loaded from a related table. So you have no clue if echo "$user.name lives in $user.city" results in 0 sql queries or one or two.

[ Parent | on HN ]
Re:How not to structure database-backed web apps: performanc... by dagw on Thursday June 28, 2018 @04:39AM (#17415107)
The ORM makes it more likely to do stuff in the application instead of the DB

Again this doesn't match my experience. A mediocre .NET developer who can access the database with LINQ is far more likely to run their queries on the database than a mediorce .NET developer who has to try to write SQL queries by hand.

And the truth is that modern ORMs are often pretty clever with their optimizations, and in many cases the ORM will often outperform an average developer doing the obvious thing is SQL.

[ Parent | on HN ]
Re:How not to structure database-backed web apps: performanc... by viraptor on Thursday June 28, 2018 @08:22AM (#17416251)
Also ORMs have enough visibility into your code to tell you of for doing stupid things. There are libraries working with ActiveRecord (and likely others too) which will warn you that you could skip the specific query if you added .eager_load(). Or about 1+N you're doing needlessly.

This can be done on SQL itself, but it would be much harder.

[ Parent | on HN ]
Re:How not to structure database-backed web apps: performanc... by threeseed on Thursday June 28, 2018 @04:04AM (#17414958)
> ORM makes it much harder to see what is going on under the hood

I've never in the last 20+ years seen an ORM that doesn't allow you to log the SQL queries with a single configuration option.

[ Parent | on HN ]
Re:How not to structure database-backed web apps: performanc... by ben-schaaf on Thursday June 28, 2018 @04:14AM (#17415002)
Heck, I'm disappointed in any ORM that doesn't log queries by default in development mode!
[ Parent | on HN ]
Re:How not to structure database-backed web apps: performanc... by asfdsfggtfd on Thursday June 28, 2018 @05:51AM (#17415453)
With an add on Django even displays them in the browser!
[ Parent | on HN ]
Re:How not to structure database-backed web apps: performanc... by paulie_a on Thursday June 28, 2018 @09:06AM (#17416496)
It's trivial to find optimizations in django debug toolbar..."oh yeah I should use select_related"

If you have no idea what you are doing with an orm you probably won't be able to write decent SQL anyways.

[ Parent | on HN ]
Re:How not to structure database-backed web apps: performanc... by nicoburns on Thursday June 28, 2018 @04:31AM (#17415079)
This is only true if you let the ORM design the schema for you. I would hazard a guess that most people only use ORMs for queries (including mutating ones). In which case you very much do know which table a field is in.
[ Parent | on HN ]
Re:How not to structure database-backed web apps: performanc... by WorldMaker on Thursday June 28, 2018 @05:30PM (#17420645)
Even if you use the ORM to design the schema for you, an ORM isn't going to just willy nilly put fields in tables by some confusing whim. Even the most opaque ORM conventions for field naming tend to have relatively easy ways to spot that MyClass.propertyName binds to table my_class and field property_name, or whatever is the case.
[ Parent | on HN ]
Re:How not to structure database-backed web apps: performanc... by pmontra on Thursday June 28, 2018 @06:16AM (#17415565)
ActiveRecord has a find_by_sql which I use for medium to complex queries. They are easier to write and understand in SQL than in Ruby. The problem is that there are many developers that don't know SQL. I found them in Ruby projects and Python and Node.js. They write whatever they manage to code with the ORM and don't understand the implications on database performance.
[ Parent | on HN ]