Railsではデータベースの構造をマイグレーションという形で統一的に管理できますが、時にはテーブルの変更に合わせて既存のデータを新しいテーブルに合うように移行する必要が出てきます。そのような場合にも、移行作業を行う場所としてマイグレーションをそのまま使うのがいいのではないか、というのが今回書こうとしている主張です。
（追記）ここで触れる、移行すべき「データ」とは、ユーザー投稿や顧客情報、操作ログといった、システムの運用に合わせて蓄積されるものを指します。「マスターデータ」と呼ばれるような、システムを稼働させるために最初から用意しておくようなデータについては、ここでは触れません。
マイグレーションに書くメリット
データを移行させる方法としては、マイグレーションに書く以外に、「手動でSQL文を実行させる」、「移行専用のメソッドを本体コードに追加する」などの方法があります。これらと比較して「マイグレーションに書く」ことのメリットをあげていきます。
ソース管理できる（手動SQLに対するメリット）
プロジェクトにSQLコードを置くような場所がないケースは多々あるので1、移行用のSQLを別管理で置いておくと、やがて忘れ去られたり、複数のサーバで移行する場合に一部だけ忘れたりしてしまいます。マイグレーションならコードベースへ一緒に置いておけますし、schema_migrationsとして実行したかも管理してくれます。
Rails的に書ける（手動SQLに対するメリット）
SQL文を書くのに慣れているなら苦にならないかもしれませんが、そうでない場合、また複数のDBエンジンで動かす可能性がある場合など、ふつうのRailsと同様にデータ処理を行えることは便利です。
責任分担の徹底（本体追加に対するメリット）
不特定多数に配布していて、移行スクリプト自体を第三者である利用者が適切なタイミングで実行できる必要がある、あるいは移行作業が機械的に行えず、人間が介入する作業のためプロンプト処理が必要になる、というようなシチュエーションであれば本体ロジックに準じる必要があるかもしれません。逆に、そうでない場合には、一回限りしか使わない移行処理を本体に取り入れてしまうと見通しが悪くなるので、マイグレーションに追い出せたほうがすっきりします。
前提条件が明確になる（両者に対するメリット）
マイグレーションは順を追って実行されるので、データベースの構造と結びついて実行される位置が明確となります。
マイグレーションに書くデメリット
公平に、デメリットについても書いておくことにします。
一般的でない手法なので、わかりづらい
最大のデメリットはこれです。ふつう「マイグレーション」はDBの構造だけを触るものなので、そこにデータまで操作を入れてしまうとわかりづらい、という見方があるかもしれません。
普通のモデルを使うと複雑化する
マイグレーションの中でモデルを使うこともできるのですが、普段使っているモデルを使うと、通常使用のために設計されている加減で「コールバックやバリデーションが邪魔になる」、あるいはバージョンが変わったことで「存在しないモデルを参照している」となってしまいかねません。後述のように、仮のモデルを作ってそれを使いましょう。
仮モデルの生成
ActiveRecordのおかげで、一時的なモデルクラスも簡単に生成できます。
class TempModel < ActiveRecord::Base
self.table_name='テーブル名'
end
もちろん、本来のクラス名を使ってもいいのですが、一時的なものだと強調するため、クラス名も違えておいたほうが混乱しなくていいでしょう。あとは、ふつうにActive Recordでデータを検索・生成してsave、updateなど何でもできます。
外部リンク
-
ある意味、「それがマイグレーション」と言えなくもないかもしれませんが。 ↩