なぜ気軽にテーブルにカラムを足してはいけないのかこの設計は、注文エンティティと発送エンティティの一部が混在してしまっている状態です。発送エンティティが混在しているのであとから発送に関する情報をもっと入れたいとなったときに、ここに追加し続けてしまうことになるでしょう。この場合も発送は別のテーブルとして切り出すのが適切です。 よくある失敗パターンとしては安直に日時(xxx_at / xxx_on)やフラグ(xxx_flag)やステータス(xxx_status)のカラムを追加することです。これらを追加したくなったときには他のエンティティではないかと疑いましょう。 変更のコストが大きい アプリケーションのリファクタリングと比べて、データベースのリファクタリングはコスト（時間・工数・リスク）が大きいです。影響範囲がどの程度あるか、既存データがどの程度あるか、ダウンタイムがどの程度許容されるか、などを考慮する必要があります。データベースのリファクタ
