Note that ‘eager loading’ and ‘preloading’ are actually the same thing. However, there are two different eager loading strategies.
The first one is by using table joins. This was only strategy available prior to Rails 2.1. Suppose that you have an Author model with columns ‘name’ and ‘age’, and a Book model with columns ‘name’ and ‘sales’. Using this strategy, Active Record would try to retrieve all data for an author and all of its books via a single query:
SELECT * FROM authors LEFT OUTER JOIN books ON authors.id = books.id WHERE authors.name = 'Ken Akamatsu'
However, this could result in many rows that contain redundant data. After having received the first row, we already have enough data to instantiate the Author object. In all subsequent rows, only the data for the joined ‘books’ table is useful; the joined ‘authors’ data is just redundant, and processing this redundant data takes memory and CPU time. The problem quickly becomes worse and worse as the level of eager loading increases (i.e. if Active Record is to eager load the associations’ associations as well).
The second strategy is to use multiple database queries, one for each level of association. Since Rails 2.1, this is the default strategy. In situations where a table join is necessary (e.g. when the :conditions option references an association’s column), it will fallback to the table join strategy.
See also ActiveRecord::Associations::ClassMethods, which explains eager loading in a more high-level (application developer-friendly) manner.