Rails doesn't have a "create table as select" construct like some
databases have. You can use ActiveRecord::Base.execute to run any
arbitrary SQL you wish. However, this makes your migration very
database-specific.
If you want to stick with the migration DSL, you need to create the
new tables, then load the data (you can use any of the AR methods like
find, create, etc.), and finally drop the old table.
If you're going to use AR methods, you should define "empty" model
classes for each of the three tables inside your migration class, so
your migration doesn't trip over validations, associations, etc.
tabase-specific.
If you want to stick with the migration DSL, you need to create the
new tables, then load the data (you can use any of the AR methods like
find, create, etc.), and finally drop the old table.
If you're going to use AR methods, you should define "empty" model
classes for each of the three tables inside your migration class, so
your migration doesn't trip over validations, associations, etc.
This also ensures that old migrations won't break as the REAL models
code evolves.
The models don't even need to be 'empty' I've found it useful to add
methods to the models 're'defined in a migration for some
manipulations.