Rails%203%20In%20Action

Database query enhancements
Indexing the data in your databases allows you to perform fast lookups and avoid
full table scans. Imagine that your database is a phonebook and that the names are in
no particular order. In this situation, it would be difficult to find all people with a
name such as John Smith-McGee, because you’d have to scan the entire phone book
to find out who has this name.
An index sorts this data into a logical order and allows for a much faster lookup.
Ever seen how a phonebook that has the letter and the first name at upper left, and
maybe the same or a different letter at upper right, with another name? That’s an
index. That allows you to easily find names because you know that the letter A comes
before B, and C after B, and so on.
Indexes allow you to run much faster queries because you tell your database how
to index the data. Although it may seem like premature optimization at this point,
you’re going to put an index on your tickets table to speed up finding collections of
tickets for a project. It’s common sense to have these from the beginning: adding
them onto large datasets will take a long time, because you’ll need to work out how to
index each record.
To add this index, create a new migration with this command:
rails g migration add_project_id_index_to_tickets
This will generate a file at db/migrate that ends with the name you’ve given it. You’re
going to need to open this file now and add in the index, because Rails cannot (yet)
read your mind. You’ll add this index inside the self.up part of the migration using
add_index and remove it in the self.down method using remove_index, like this:
def change
add_index :tickets, :project_id
end
Run this migration using rake db:migrate db:test:prepare to run it on the development
and test environment databases. You’ll see this line in the output:
-- add_index(:tickets, :project_id)
-> 0.0015s
Just to reinforce the message: it’s better to add the indexes when the database is first
being designed rather than at a later point because this 0.0015 seconds could easily
become whole seconds on a larger dataset. This index will now group your tickets into
groups of project_id columns, allowing for much faster lookups to find what tickets
belong to a specific project.
You want the absolute best performance you can get out of your database because
it’s a key point in your requests. Indexes and eager loading are the two most basic ways
you can get better performance out of your database.
If your database is performing optimally and your pages still aren’t loading fast
enough, you’ll need to look for alternative methods of speeding them up. Two of
these methods are page and action caching, which allow you to store the output of a
page to serve it up rather than re-processing the code and hitting the database again.
447