I’m just getting into Rails and it seems very cool so far. However I’m
having trouble understanding why Migrations are so important.
For past projects I’ve always used SQL comparison tools to record schema
changes, and later play them back when it’s time to install a fresh DB.
It’s fast, simple and it works.
On the other hand With Migrations…to me it just seems like one more
thing I have to write and one more thing that can go wrong.
What are some good reasons for me to use Migrations versus SQL scripts?
What are some good reasons for me to use Migrations versus SQL scripts?
SQL scripts can’t massage the existing data using domain logic to
jive with the new schema.
SQL scripts don’t usually have easy ways to back out of a change
(migrate down).
SQL scripts don’t maintain a schema version automatically, so teams
have to manually deal with when to run what and how.
SQL scripts are bound to 1 database, so they’re not portable. And
they make it easy to introduce proprietary constructs, so the entire
schema is rendered unportable.
Whats the best way to handle scheme update slike adding/droping relation
ships and indexes? Embed SQL into the migration?
DHH wrote:
What are some good reasons for me to use Migrations versus SQL scripts?
SQL scripts can’t massage the existing data using domain logic to
jive with the new schema.
SQL scripts don’t usually have easy ways to back out of a change
(migrate down).
SQL scripts don’t maintain a schema version automatically, so teams
have to manually deal with when to run what and how.
SQL scripts are bound to 1 database, so they’re not portable. And
they make it easy to introduce proprietary constructs, so the entire
schema is rendered unportable.
You may want to checkout Agile Web D. 2nd edition which
contains a chapter on migrations. Or the API. Relationships are done
through the model / class files. And there are also some interesting
plugin’s for associations as well.
Try doing that with an 8 TB database, with a maximum allowed downtime
of 1 hour, when an entire team’s salaries are measured in minutes of
downtime.
A streaming migration that maxes out both the originating and target IO
systems can just barely do it. Unload and reload via SQL scripts takes
at least 3 times as long.
Whats the best way to handle scheme update slike adding/droping relation
ships and indexes? Embed SQL into the migration?
Yes. Use the execute command for SQL not covered by the migrate syntax,
like
this example:
execute "ALTER TABLE items ADD COLUMN cost_unit DECIMAL(5,2) NOT
NULL
DEFAULT 0"
For relationships, you might want to take a look at the
foreign_key_migrations plugin, which will automatically set up the
relationships in your schema based on your field names. Has worked well
for
me and a nice shortcut.