On Sep 22, 9:01 pm, Fernando P. [email protected]
wrote:
Have you tested? because at the time of Rails 1.2.6 where the :include
created a gigantic JOINs, my custom :joins was at least x3 times faster!
mostly because I only pick the fields I really need and because AR
doesn’t create full objects with their references and all the stuff.
Yeah, in my case the Rails 2.1 :include was significantly faster than
a :join for multiple has_many relationships, like:
class Depot
has_many :trucks
has_many :containers
has_many :cranes
end
Of course, we may be talking about apples and bananas here, since my
example involves has_many associations while the scenario I could
think of given your description is a belongs_to or has_one.
I agree that belongs_to or has_one associations are better off piggy-
backed via a :join and :select, but using them eventually leads into a
lot of repetitions in our code. That’s why I prefer using the Simpler
Piggy-Backing plugin:
http://railsexpress.de/blog/articles/2006/05/29/simpler-piggy-backing
The author even claims: “In fact, using the extension is slightly
faster than coding the select and joins manually (1%-3%).”
I tried finding some info on MySQL forums and websites about 1 query
with multiple JOIN versus multiple queries, but it is not clear which is
more efficient.
The Depot example I mentioned earlier is better composed using atleast
2 SQL statements, as against a single one. Not only would the single
SQL approach (using joins) produce a cartesian product, it is
logically incorrect since trucks, cranes and containers are
independent of each other.
Then again, it all boils down to AR being ridiculously slow in
composing AR objects from a resultset.
Things get really complicated when I read: “How adding another table to
JOIN can improve performance ?”
http://www.mysqlperformanceblog.com/2008/08/01/how-adding-another-tab…
There are a lot of quirks to doing optimizations in MySQL. The “one
index per one query” is one, which is why I usually shy away from
MySQL when doing data warehousing. I tried using it once to do CDR
(call detail record) reporting, but the performance was such a
nightmare that I had to migrate it to Postgre.