プロジェクトが大きくなると、マイグレーション数がかなり高くなります。振り返ってみると、リファクタリングできる移行が多数見られます。同じようにcreate_postsとrename_posts_to_responsesをcreate_responsesにマージする。Ruby on RailsでDBマイグレーションをリファクタリングする
これは悪いハビットですか？また、リファクタリングによる移行を促すべきですか？
プロジェクトの後半では、実際に移行をすべて実行してはならない場合は、schema:loadとする必要があります。つまり、プロジェクトの完全に新しいインスタンスを開始する必要がある場合。私の経験では、あなたは何よりも頭痛の種を増やしています。
schema:loadを実行するのは、マイグレーションにデータを含めると（ちょっと私たちにとってはうれしいことですが）、少し難しくなります。
私は、すべての移行がschema.rbから取得された1回の移行で置き換えられる大きなプロジェクトを見てきました。これは、データ移行を使用しないで、代わりに一連のシードデータを維持する別の理由です。私の意見では
開発中にリファクタリングしても大丈夫である[チームの一員として働いていたとき、私は特にそれを思いとどまらでしょうけれども]、それはリファクタリングの移行
をによって台無し生産のアプリケーションに簡単すぎるあなた回ソースコントロールへの移行をチェックインして、変更しないことをお勧めします。 1つのバグがある場合、私はまれな例外を作りますが、これは非常にまれです（おそらく100に1）。
野生の中にいったん出ると、一部の人がそれらを動かすことがあります。それらはdbで完了したとして記録されます。変更して新しいバージョンをチェックインすると、他の人が変更の恩恵を受けることはありません。特定の変更をロールバックして再実行するようにユーザーに依頼できますが、これは自動化の目的に反するものです。しばしば、それは混乱になります。それはより良いです。
多数の移行が行われると、不便を感じる可能性があります。しかし、一般的には、それほど多くを実行することはありません。私たちがこれを行う唯一の場所は、毎回データベースを削除して再作成する統合サーバーです。だから、あなたはそのディレクトリを開いてそこにいないふりをすることはできません。
移行を統合する方法があります。これを行うには、現在のスキーマを移行にコピーし、以前のすべての移行を削除します。その後、管理するファイルが少なくなり、テストはより速く実行できます。特に、運用環境で自動的にマイグレーションが実行されている場合は、これに注意する必要があります。私は一般的に、誰もが新しいスキーマで動いたことを知っている移行を置き換えます。他の人はこれを行う方法が少し異なります。