# Db:migrate vs. MySQL dump or good ol' DDL **URL:** \ **Category:** Rails\ **Created:** [May 15, 2007, 3:16pm UTC](https://www.ruby-forum.com/t/db-migrate-vs-mysql-dump-or-good-ol-ddl/104215 "2007-05-15T15:16:02Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![keith](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/f05b48/32.png) [@keith](https://www.ruby-forum.com/u/keith)\ **Post date:** [May 15, 2007, 3:16pm UTC](https://www.ruby-forum.com/t/db-migrate-vs-mysql-dump-or-good-ol-ddl/104215/1 "2007-05-15T15:16:02Z")
Have people run into issues using db:migrate where you have gone back to using MySQL dumps or DDL? We are a first time Rails development team and are trying to decide if we should use db:migrate in production. What are people’s opinion’s and experience with using db:migrate in production environments? ---
**Author:** ![keith](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/f05b48/32.png) [@keith](https://www.ruby-forum.com/u/keith)\ **Post date:** [May 15, 2007, 3:22pm UTC](https://www.ruby-forum.com/t/db-migrate-vs-mysql-dump-or-good-ol-ddl/104215/2 "2007-05-15T15:22:03Z")
> Have people run into issues using db:migrate where you have gone back > to using MySQL dumps or DDL? We are a first time Rails development > team and are trying to decide if we should use db:migrate in > production. What are people’s opinion’s and experience with using > db:migrate in production environments? Absolutely use migrations from day one. I use the mysql console for 1 thing: creating the database. Everything after that is done via migrations. I will periodically dump production and load it into development, so I’m developing on a semi-current set of data, but I never ever ever touch the production database directly. Seriously. Use migrations. They are a Good Thing and will make your life much easier in the long run. ---
**Author:** ![keith](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/f05b48/32.png) [@keith](https://www.ruby-forum.com/u/keith)\ **Post date:** [May 15, 2007, 4:40pm UTC](https://www.ruby-forum.com/t/db-migrate-vs-mysql-dump-or-good-ol-ddl/104215/3 "2007-05-15T16:40:15Z")
I use MySQL dumps for backups, and I’d never leave migrations. It was a bit of a learning curve to get the team used to the idea, and I seemed to be always going back to the API to get the few options stuck in my thick head, but now that I’ve made the switch, I’ll never go back. If it were just an alternative way to load data definitions, that would be one thing. But it’s also: 1. easier to see the evolution of the data structure without checking out different versions of a single file 2. a whole lot easier to see-saw when debugging model issues (I just rake db:migrate VERSION=12; rake db:migrate whenever I’ve got a problem with the data/models in version 13, say.) 3. quicker to make database changes 4. easier to manage differences between databases (I use PostgreSQL, MySQL, and SQLite for different projects, and the data requirements between these are a lot simpler to manage in migrations than dumps or DDLs.) I’ve heard that all those migrations get unwieldy after a while. I can see their point. I’ve dealt with projects with 50 and 60 migrations. But, that’s easy to fix. Just take a current db/ schema.rb file and convert it into a migration (create a class and up and down methods). Then, you can replace those 50 or 60 migrations with one migration file.