Using migrations in new Rails project

Question

I am starting on a new Rails project and I wonder what I should do when it come to the database. Should I skip using migrations and keep the database scripts separate from the Rails project, or should I use migrations? By creating the database "manually" won't you get better control? Is that how it should be done?

Answer 1

The creation of the database should be done through Rails as it'd pretty much get all that set up for each of your environments.

As for migrations, the Rails core team worked very hard to have migrations compatible with all the different databases from postgresql to mysql to even oracle. While a lot of the operations can be achieved with migrations with a lot more ease than creating your own tables, they still give you the flexibility to add your own SQL into the mix.

Take a look at this migration where I create the extension for HSTORE for a postgresql database.

class SetupHstore < ActiveRecord::Migration
  def up
    execute "CREATE EXTENSION IF NOT EXISTS hstore;"
  end

  def down
    execute "DROP EXTENSION IF EXISTS hstore;"
  end
end

This means that you can pretty much execute any command that you want from your migrations. Notice, using Rails migrations give you the flexibility to rollback migrations by adding an up and down method in which you rever the migration. There's a lot of neat things you can do in migrations.

Also, rails also gives you the option to dump your migrations as Ruby or as SQL for things like HSTORE that are not possible to achieve with Ruby. This option is found under the application.rb file under configurations.

In the end, if you are going to use Rails you might as well use all the things it provides you to ease your development.

You should read the guide on Rails migrations to give you more of an insight on them before you go off manually creating your database.

Rails Migrations

Answer 2

I think you should use migrations. They make sure that your code and your database are "in-sync" and you don't try to run code on an older table.

For example, when you deploy a new version of your app to production and you don't use migrations, you have to do the work on your db twice: In development and production. And let there be a staging env, even more work.

Another benefit is, that with migrations, you can quickly "transform" your dev db to an older stage (in my case, I need this feature from time to time).

Or if its applicable for your project, use a schema-less db like MongoDB. There you can define your Models inside your code and you don't have to worry about migrations. But watch out when you're in production: Maybe you have to migrate data from one column to another ;)

Answer 3

Creating the database migration files manually isn't a good idea in terms of rails perspective. It is just like you have a gem with a lot of functionality and then you are implementing the logic of your own that provides the same functionality as gem.

This will not only consume time but also may create problems in versioning of migrations and schema loading if you do any updation later.

The trick is to create a migration, scaffolds quickly by the command:

rails g scaffold scaffold_name index create name:string 

This will create the scaffold according to what you give in the command line like the above one will create scaffold with the scaffold_name and create two methods index and create and one field with name as a string.

Similarly, you can add a column with a single command line using migration:

   rails g migration add_field_name_to_table_name email:string 

Or delete a column that you don't want with a migration:

rails g migration remove_field_name_from_table_name email:string 

You can even rollback migrations to the previous one with:

rake db:rollback will get you back one step

You can migrate to any version with:

rake db:migrate VERSION = "434483468726583" where "434483468726583" is the migration version number to switch to.

Like so there are many commands to work with rails migrations .

All in all, whatever you want with a migration, you can get with commands easily.

Answer 4

Migrations are there to replace DB scripts. Since they are easier to manage and they are interoperable. When it comes to further configure your database, you can add code to scripts that you manage independently, but this is useful only when you want to do something specific to the database system you're using and migrations don't cover those cases.

Answer 5

Rails migrations are tasks that change the structure of your database -- ie they make changes to your schema. Migrations are great for enforcing the underlying structure of a relational database and are a good idea to use when getting started and when working with other people; however, be aware that there are a number of limitations and drawbacks. For example, when you create validations in your models, sometimes these validations are not enforced at the database level, making data integrity only maintained at the application-level.

Over the course of time, you'll make a lot of changes to your models as your application and product (business logic) evolve. Given that migrations are tracked through time with timestamps, it can get really hairy to enforce that migrations are applied in production at the right time, and in the right order, while working on a relatively large team.

A non-relational database, such as MongoDB, embraces model evolution by allowing for some schema flexibility. For example, if you want to add a field to a model, you can just simply start saving data in that field instead of having to run a migration to change the database structure. Most people say MongoDB is "schemaless", but it's more accurate to say that MongoDB allows for "schema flexibility." Check out the Mongoid gem for defining models using MongoDB. It might be worth using MongoDB and Mongoid if your application is going to be exploratory and potentially change a lot over the course of time.