Migration up and down

That way you can create versions of your database. Your development
server mabey has version 10 of the DB while the production server only
has version 6.
Next part of the scenario is that you are posting the newest version
of the code to your production server. But wait. Something doesn't
work. Then you can quickly do back the command rake db:migrate
VERSION=6 to move back the database to the point it was.

That is only one scenario of why it's nice to have migration versions.

Each version of the database is handled by it's own file. For example
when you have an online store app and you are adding comments to the
products you would add the 010_add_comments.rb migration file. You
never change an active version. If your database is version 10 the
file you should be changing is version 11. In emergency while in
development mode you could rake it down a version and then change the
migration file and rake it up.

The problems with doing everything automagically (love that word) is
that it simply reduces what you can do. Remember that the migration
scripts are just plain old Ruby with some DSL. You can put pretty much
anything inside those scripts. It's not really uncommon to add some
file handling into there. Such as copying files around or deleting
some old temporary files. Anything you can do in Ruby you can do
inside those migrations. The power of it goes way beyond databases
even though DB work is it's main function.

It just makes sense to allow commands for both up and down versioning.
It's not a lot of extra work for the programmer but it just simply
gives him a lot of extra options.

However to save some time. If you are lucky enough to use TextMate
then the excellent SyncPeople on Rails plugin can automagically add
the down command while you create the up command. Or vise-versa.