Performance vs normalization best practice

I have a common situation and would like best practice suggestions from
some
of you more experienced rails developers.

In my DB I’ve normalized tables in a traditional manner, e.g. I have
Posts
which have authors stored in a Users table.

My problem is when I go to show a list of Posts and I want to display
the
author name (e.g. post.author.name)
ActiveRecord appears to do a SELECT on the Users table for each post.
If I
want to display additional author properties
(e.g. phone_number), additional queries are generated. Clearly this is
a
performance penalty for my normalization.

What’s the recommended way for avoiding the performance penalty WITHOUT
de-normalizing?

In C# or Java I’d cache the “static” User data and do in-memory lookups,
but
in Rails I’m not sure how I’d set up such a cache
even if that were the right solution.

Thanks in advance.

You could try:

Post.find(:all, :include => :author)

This is on p244 of “Agile Web D. with Rails”, which mentions
that this will only work for databases which support LEFT OUTER JOIN. It
is designed to avoid just the situation you are having by preloading the
child rows.

Julian

Scott R Brittain wrote:

(e.g. phone_number ), additional queries are generated. Clearly this
is a performance penalty for my normalization.

What’s the recommended way for avoiding the performance penalty
WITHOUT de-normalizing?

My piggy back plugin seems to address this issue.

See
Simpler Piggy Backing.

– stefan


Rails performance tuning: RailsExpress.blog
Subscription: railsexpress.de

On 6/24/06, Julian G. [email protected] wrote:

You could try:

Post.find(:all, :include => :author)

This is on p244 of “Agile Web D. with Rails”, which mentions
that this will only work for databases which support LEFT OUTER JOIN. It
is designed to avoid just the situation you are having by preloading the
child rows.

Julian

This is called ‘eager loading’ if you’d like to google for more
information.

Isak