2025/10/31 20:06 Using the expand and contract pattern for schema changes
やあ、ロボ子。今日はデータベースのスキーマ変更について話すのじゃ。
博士、こんにちは。スキーマ変更、重要ですよね。特にダウンタイムを避けたい場合は。
そう！そこで「expand and contract pattern」の出番じゃ！
expand and contract pattern…ですか？初めて聞きました。
これは、システムを止めずに、古いデータ構造から新しいデータ構造へ段階的に移行する方法なのじゃ。記事によると「データベースのダウンタイムなしに、古いデータ構造から新しいデータ構造へ移行するための多段階プロセス」らしいぞ。
なるほど！段階的に移行することで、リスクを減らせるんですね。
その通り！それに、問題が起きた時や要件が変わった時にも、簡単にロールバックできるのが強みなのじゃ！
具体的な手順はどんな感じなんですか？
まず、新しいスキーマを構築してデプロイするのじゃ。既存のカラムは変更せずに、新しいカラムを追加する。記事にも「既存のカラムを直接変更せず、新しいカラムを追加」って書いてあるぞ。
並行して実装するんですね。次に何をしますか？
インターフェースを拡張して、新しいカラムとテーブルを認識させるのじゃ。クライアントコードは、古いデータ構造から読み込みつつ、新しい構造にも書き込むようにする。
両方に書き込むことで、データの整合性を保つんですね。
そうそう！そして、既存のデータを新しいスキーマに移行する。データの型変換とか、値の分割が必要になることもあるぞ。
移行スクリプトが必要になるんですね。その後は？
新しいインターフェースをテストして、ちゃんと動くか確認！機能テストやパフォーマンステストは必須じゃ。
テストが大事ですね。それが終わったら、いよいよ切り替えですか？
そう！新しいインターフェースに読み込みを切り替えるのじゃ。クライアントの動作を変更して、新しいスキーマからデータを読み込むようにする。
そして、古い構造への書き込みを停止するんですね。
その通り！最後に、古いデータ構造をシステムから削除すれば完了じゃ！
なるほど、段階的な手順で安全にスキーマを変更できるんですね。記事に`equipment`テーブルの例が載っていましたね。
`equipment`テーブルの`city`、`park`、`playground`カラムを、新しい`playground`テーブルに置き換える例じゃな。まず`playground`テーブルを新規作成して、クライアントアプリケーションを更新し、両方のテーブルに書き込む。その後、古いデータを移行するスクリプトを実行するのじゃ。
クライアントアプリケーションの設定を変更して、新しいテーブルから位置情報を取得するようにして、古いテーブルへの書き込みを停止、不要なカラムを削除する、と。
記事にはPrisma Migrateを使う方法も書いてあるぞ。Prismaスキーマに基づいてマイグレーションファイルを生成して、データベースに適用できるらしい。
便利ですね！Prismaを使うことで、マイグレーション作業が楽になりそうです。
そういうことじゃ！データベースのスキーマ変更は、慎重に進める必要があるからの。expand and contract patternをマスターして、スマートなエンジニアになるのじゃ！
はい、博士！頑張ります！
そういえばロボ子、データベースのスキーマ変更って、まるで部屋の模様替えみたいじゃな。家具を移動する前に、どこに置くかちゃんと計画しないと、大変なことになるからの！
確かにそうですね！でも、博士の部屋はいつも散らかっていますよね…。
むむっ！それは言わない約束じゃなかったかの！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。
