Re:It's not Ruby that's slow, it's your database
by JohnBooty on Tuesday November 08, 2022 @11:20PM
(#33527480)
I agree with you, however, some ORMs handle this fairly elegantly.
At that point it's far easier to write the query in
straight SQL and produce a straightforward mapping
into the record structure, which doesn't play well
with the ORM because that bypasses its entity cache,
which causes another huge set of problems on its own
Rails' ActiveRecord ORM offers at least two ways to handle this.
1. ActiveRecord plays really nicely with views (including materialized views) in my experience. It treats them just like tables, basically, except you can't write to them. (note: there may actually be some cases where you can write to them; not sure)
2. You can supply your own handrolled SQL to ActiveRecord, e.g. `User.find_by_sql("select a,b,c from blahblahblah")`
YMMV obviously but I've been working with Rails since 2014 but this has covered all of my performance needs.
Plain old ActiveRecord default query generation is fine 99% of the time, and it's rather elegant/easy to sidestep it when I wish.
1. ActiveRecord plays really nicely with views (including materialized views) in my experience. It treats them just like tables, basically, except you can't write to them. (note: there may actually be some cases where you can write to them; not sure)
2. You can supply your own handrolled SQL to ActiveRecord, e.g. `User.find_by_sql("select a,b,c from blahblahblah")`
YMMV obviously but I've been working with Rails since 2014 but this has covered all of my performance needs.
Plain old ActiveRecord default query generation is fine 99% of the time, and it's rather elegant/easy to sidestep it when I wish.