マイグレーションについて質問させてください

Question

今は一人で開発しているのでマイグレーションを使わず、必要に応じて直接DBを操作しています。しかし将来チーム開発になったときのことを考え、マイグレーションを活用したいと考えています。そこで色々ネット上の記事を読んだのですが、全体感が分からないので質問させてください。

1.マイグレーションファイルを生成する単位
テーブル作成、カラム追加など、何か変更を加えようとするたびにファイルを１個ずつ追加するのでしょうか。また１つのファイルの中に、複数テーブルに対する変更は１ファイル内に記述できるのでしょうか。

2.ファイル名には意味があるのでしょうか
環境構築すると、サンプルとして2014_10_12_000000_create_users_tables.phpというファイルが出来あがります。
この「2014_10_12_000000」の部分は、ロールフォワード・ロールバックする際の時系列の判断のために参照されているのでしょうか。それともファイルのタイムスタンプが参照されているのでしょうか。
その先の「create」や「users_table」にはシステム上の意味や制約はあるのでしょうか。（質問1と関連しますが）

3.マイグレーションファイルを手作業で作成して問題はありますか。
php artisan make:migration tablename を使っても、出来上がるファイルの中身はほとんど空なので、あえてコマンドを使う意味が分かりません。既存のファイルをコピー・編集して新規ファイルを作成することに問題はありますでしょうか。（質問1・質問2の結果にも多少影響を受けますが）

4.モデル内の記述変更を伴うようなテーブル設計変更（プライマリキーを変える、複数DBを相手にするなど）の場合、マイグレーションではどのように管理するのかがイメージできません。

以上、ご教示いただけますと幸いです。よろしくお願いいたします。

Answer 1

長文で申し訳ありません。

---

1.マイグレーションファイルを生成する単位

システム的な制約はありません。
1つのマイグレーションファイルから複数のテーブルを作成したり、複数のデータベースに対して操作をしたりといった事も一応可能です。
テーブル単位で、機能としてまとまった括りで、あるいは機能改修や要件毎でと、分割単位は人によって変わる部分でもあります。
テーブルの作成と、外部キーの付与を別のマイグレーションにするといった方法もあります。

---

2.ファイル名には意味があるのでしょうか

ファイル名は、以下の目的で利用されます。

• マイグレーションを行う順番のソート
• 既にマイグレーションを行ったかどうかの判定
• マイグレーションファイルのクラス名との結びつけ

適当な名前でも大丈夫か？というと答えはNOなのですが、テーブル作成するならcreateや、対象のテーブル名をファイル名に含めないといけないか？と言うとそれもNOです。
以下、上記の考慮すべき内容を補足します。

migrateコマンドにより一度に複数のマイグレーションファイルを実行する場合、
ファイル名をphpのsort関数にかけた上での順番で実行されます。
外部キーなどの付与などは親テーブルが存在しないといけませんから、順番を考慮するケースはあります。

一度マイグレーションを行ったファイル名は、migrationsテーブルに格納されます。
適用済みかそうでないかの判定材料に使われるのですが、マイグレーション適用後にファイル名を変更すると、別物として認識されてしまいますので、途中での変更はやめた方がいいでしょう。

更にマイグレーション時、クラスをインスタンス化するため、クラス名をファイル名から作成するのですが、以下のような事をやってます。

implode('_', array_slice(explode('_', $file), 4));

$class = Str::studly($file);

ファイル名をアンダーバーで分割した時に、最初の4つを捨てた残りで組み立てています。
つまり、2014_10_12_000000_create_users_tables の日付時間の部分を除外し、
残ったcreate_users_tablesでCreateUsersTablesというクラス名を求めています。
なので、ファイル名と、そのファイルの中のclass名がちぐはぐだと正しく動きません。

これらを考慮した上でならファイル名は自由ですが、とはいえやはり
php artisan make:migrationで作成される書式に合わせるのが楽かと思います。

---

3.マイグレーションファイルを手作業で作成して問題はありますか。

手動でも特に問題ありません、が、コマンドで作ると、上で説明したような
意味のあるファイル名と連動したクラス名を自動的につけてくれる他、
内部で自動的にcomposer dump-autoloadを行ってくれるので、楽にはなるかなと。

---

4.モデル内の記述変更を伴うようなテーブル設計変更

例えば元々主キーのカラムがkey1だったのに、key2になったという場合は以下のように書けます。

Schema::table('some_tables', function ($table) {
    $table->dropPrimary('key1');
    $table->primary('key2');
});

複数DBを相手にするというのがちょっとわかりませんが、
Schemaのconnectionメソッドで、接続先のdatabase設定を切り替えられます。

Schema::connection('hoge')->table('some_table', function () {
    //
});

これで答えになっていますでしょうか？

Comments

[退会済みユーザー]

Archsted様、丁寧な解説を付けていただき、ありがとうございます。
想像していたより遥かに複雑なことを内部的にはやっているということが分かりました。
ひとまず開発にマストの機能ではないのでスキーマ変更等は別で管理することにいたします。ただいつまでも分からないままにはしたくないので、テスト環境で試しながら理解していきたいと思います。ありがとうございました。