make more explicit benefits of migrations and ruby vs mysql

1 files changed, 2 insertions, 2 deletions

diff --git a/railties/doc/guides/migrations/migrations.txt b/railties/doc/guides/migrations/migrations.txt
index 5af9ea633b..ad20dcdf93 100644
--- a/railties/doc/guides/migrations/migrations.txt
+++ b/railties/doc/guides/migrations/migrations.txt
@@ -1,9 +1,9 @@
 Migrations
 ==========
 
-Migrations are a convenient way for you to alter your database in a structured and organised manner. Active Record takes care of working out which migrations have already been run so you can just update your source and run the migrations, leaving Active Record to work out the details.
+Migrations are a convenient way for you to alter your database in a structured and organised manner. While you could edit fragments of SQL by hand it would then be up to you to tell other developers that they need to run your scripts when they next pull changes. You'd also have to keep track of which changes need to be run against the production machines next time you deploy. Active Record tracks which migrations have already been run so all you have to do is update your source and run `rake db:migrate`. Active Record will work out which migrations should be run.
 
-Migrations also allow you to describe these transformation using ruby, in a database independent way (you can drop down to raw SQL for database specific features).
+Migrations also allow you to describe these transformation using ruby. The great thing about this is that (like most of Active Record's functionality) its database independent, you don't need to worry about the precise syntax of CREATE TABLE any more that you worry about variations on SELECT * (you can drop down to raw SQL for database specific features). For example you could use SQLite3 in development, but MySQL in production.
 
 You'll learn all about migrations including: