【すきーままいぐれーしょん】
スキーママイグレーション とは？
最終更新:
💡 DBの設計変更を、手順と履歴で管理する
データベースのテーブルや列などの構造を、変更手順と適用履歴を管理しながら移行すること。変更を共有・再現しやすくするが、無停止や失ったデータの復元を自動で保証するものではない。
📌 このページのポイント
ひよこ 手動でALTER TABLEするのは、だめなの？
ペンギン先生 SQL自体がだめなのではないよ。いつ、どの環境へ、何を変更したかを共有しないと、後から追いにくいんだ。変更をファイルなどに記録して、ツールで適用履歴を管理すると、順序をそろえたり未適用の変更を確認したりしやすくなるよ。
ひよこ ツールなら、環境の差は絶対に出ない？
ペンギン先生 手助けにはなるけれど、保証ではないよ。ツールを通さずに変更したり、適用に失敗したりすれば差は生まれる。Railsはschema_migrationsに適用履歴を持つけれど、実際のDB構造の正しさも確認する必要があるんだ。
ひよこ 本番に適用するときは、何を見るの？
ペンギン先生 アプリが新しい構造に対応できるか、変更がどのロックを取るか、書き換えが必要かを確認しよう。PostgreSQLでは、列追加でも条件によって書き換えの有無が違う。事前の試験、所要時間、バックアップや復旧手順を考え、使うDBとバージョンの資料を読もう。
ひよこ ロールバックすれば、全部元に戻る？
ペンギン先生 構造を戻せる変更と、失われたデータを戻せることは別だよ。たとえば列を削除した後、同じ列を作り直しても中身は復元されない。Railsも不可逆な変更を扱っている。戻す機能や手順はツール・操作で異なり、万能な取り消しボタンではないんだ。
ひよこ 変更は、どう分けると進めやすい？
ペンギン先生 列を置き換えるなら、新しい列を追加し、必要なデータを移して、アプリを切り替え、古い列を使わなくなってから削除する方法があるよ。Expand and Contractと呼ばれる。図はその考え方の例。互換性や移行中の読み書き、検証を設計し、実際の適用後の状態も確かめよう。
もっと詳しく知りたい人へ
適用済みの変更ファイルを、後から書き換えてもいい？
他の環境へ共有・適用したファイルを書き換えると、同じ履歴でも実際の構造が違う状態を招きます。Railsのガイドも、共有済みの変更を直接編集するより、新しいマイグレーションで修正する方法を案内しています。利用するツールの履歴・検証の仕組みに従いましょう。
まとめ：ざっくりこれだけ覚えればOK！
「スキーママイグレーション」って出てきたら「DBの構造変更を、手順と適用履歴で管理する仕組み」と思えばだいたいOK！
📖 おまけ：英語の意味
「Schema Migration」 ＝ スキーマ移行
💬 Migration（移行）の名前通り、DBスキーマを現在の状態から次の状態に「移行」するよ