Rails does not specify the mapping of models to database schema, so it requires specification of migrations instead to document changes to the database that go along with any code changes. So migrations are explicit commands (in a pretty simple dsl) to add columns etc. spread out over many files as the application evolves. This means each schema change requires adding a migration file with those changes in it, rather than modifying a master schema or mapping. There is a schema.rb file but it is created/modified automatically.
There are trade-offs to each approach but it is probably one of the areas that Rails could still improve by looking at other ORMs - I'd prefer to see the schema specified along with constraints etc for each field at the top of each model to make it explicit and self-documenting, and perhaps doing away with migrations altogether.
Comments
Rails does not specify the mapping of models to database schema, so it requires specification of migrations instead to document changes to the database that go along with any code changes. So migrations are explicit commands (in a pretty simple dsl) to add columns etc. spread out over many files as the application evolves. This means each schema change requires adding a migration file with those changes in it, rather than modifying a master schema or mapping. There is a schema.rb file but it is created/modified automatically.
There are trade-offs to each approach but it is probably one of the areas that Rails could still improve by looking at other ORMs - I'd prefer to see the schema specified along with constraints etc for each field at the top of each model to make it explicit and self-documenting, and perhaps doing away with migrations altogether.