実践！データベースリファクタリングツール
- 2. 開発中のデータベース スキーマの変更 正直避けられない 開発中 出来ればデータを消さずにスキーマを変更したい 運用中 絶対にデータを消さずにスキーマ変更する -> 楽はしたいがデータが消えるのは困る
- 3. データベース スキーマ変更管理の課題 情報の一元化 マスタの情報と差分情報がバラバラになって一元管理されずにズレが生じる場合がある データの消失の防止 特に運用中は必須 管理の容易さ 複数 DBMS への対応
- 4. データベース変更管理ツール ( データ準備型 ) 初期データを用意して、スキーマ変更の度にスキーマを作り直して初期データをロードし直す ツール S2JDBC-Gen 、 Jiemamy 利点 管理するのは最終的なスキーマ情報だけで良い 毎回スキーマを作り直すのでどんな変更でも対応できる 欠点 用意したデータを使うので開発者ごとに違うデータを使ったりするのは難しい データの管理が面倒くさい 開発環境には良いが本番環境のスキーマ差分更新に使えない
- 5. データベース変更管理ツール ( 差分管理型 ) スキーマ変更の差分情報を蓄積して、稼働中のデータベースに差分を適用することによりスキーマを更新する ツール ruby on rails の migration 、 LiquiBase 利点 開発環境にも本番にも同じスキーマ更新方法が適用できる データが消えないので、開発者ごとに違うデータを使ったり出来る 欠点 差分情報の管理が面倒 (SQL だったり、 XML だったり、 YAML だったり ) 差分情報と別に最終的なスキーマ情報も必要で一元管理しにくい
- 6. Liquibase の diff 機能 差分管理型の欠点を解消するのが Liquibase の diff 機能 2 つのデータベースの差分を見て、差分情報を出力してくれる (XML または SQL 形式 ) これにより差分データの管理が軽減できるし、差分データは生成されるのでマスタとなるスキーマ情報さえあればよい 作成された差分データは Maven2 、 Ant 、コマンドラインツール、 ServletListener などで適用可能
- 7. diff機能の操作手順 マスタとなるスキーマ情報を更新する 新しいスキーマのデータベースを作る ( データなどは空でよい ) 古いスキーマのデータベースと比較してスキーマの差分情報 (XML または SQL) を出力する 差分情報を使用中のデータベースに適用すると最新のスキーマになる DB （差分用） DB （使用中） スキーマ 情報 ( マスタ ) ②上書き ③比較 生成 スキーマ 情報 ( 差分 ) ④適用
- 8. diffでは出来ないこと 名前の変更 ( テーブル名、カラム名など ) 例えばテーブル A が B に変更されても元の名前がわからないので基本的にテーブル A を削除してテーブル B を追加になる データが消えると困る場合は別途対応が必要 変換不可能なデータ型の変更 現状の型より厳しい型への変更はほぼ無理 例：文字列->数値、日付 ※ そもそもそんなの alter 文で変更不可能だから機械的には無理 制約の追加や制約のある列の追加 デフォルト値を付けない限りは列を追加したときは値が null になるので、制約があるとエラーになることが多い。
- 9. そういう場合は SQL を書けばいいじゃない w XML ファイルの中に SQL を書くことが出来る XML で書いても良いが本番適用を考えると SQL が無難
- 10. XML vs SQL XML だと DBMS の違いを吸収してくれる どこまで差分を適用したかを管理しているので、適用されていない差分だけ適用してくれる SQL だと…以下略 おすすめは 開発環境には手軽に使える XML 本番環境には中身が確認できる SQL
- 11. まとめ データベーススキーマの変更管理を楽にしたい 運用中の本番対応を考えると差分更新が現実的 机械的に出来るところはツールで、出来ないところは人が対応