well it was incredibly informative (thanks!), but you do not have the problem of schema changes.
In a traditional DB, one needs to manage addition and deletion of columns, during the development of a project. And one needs to be able to synchronize these database schema changes with the rest of the team.
And it is nice to have these as incremental (yes there is the obvious waste of creating a column in one migration and dropping it in the other)
Migrations also allow you to do stuff like add indexes etc to your tables and is not just a one-to-one mapping of your objects to the DB.
Which is why migrations (Rails and Django's South) are so extremely helpful during development.
One of the things I that was for something like Linq (Scala has something called squeryl) and you could have your database created from your objects - not optimal, but enough to start with.
FWIW, ease of managing incremental schema is why Drupal (using drush and "Drupal Features" ) is one of the better PHP frameworks.
Comments
well it was incredibly informative (thanks!), but you do not have the problem of schema changes.
In a traditional DB, one needs to manage addition and deletion of columns, during the development of a project. And one needs to be able to synchronize these database schema changes with the rest of the team. And it is nice to have these as incremental (yes there is the obvious waste of creating a column in one migration and dropping it in the other) Migrations also allow you to do stuff like add indexes etc to your tables and is not just a one-to-one mapping of your objects to the DB.
Which is why migrations (Rails and Django's South) are so extremely helpful during development.
One of the things I that was for something like Linq (Scala has something called squeryl) and you could have your database created from your objects - not optimal, but enough to start with.
FWIW, ease of managing incremental schema is why Drupal (using drush and "Drupal Features" ) is one of the better PHP frameworks.