１つのサービスを拡張させていると、テーブルの再設計が必要になる時があります。自分が経験したのだと、顧客マスタ群とか、商品マスタ群とか。
使ってないカラムや冗長なフラグ、無駄に分かれたテーブルなど目に余るようになったらリファクタしましょう。そんなテーブルリファクタリング時の失敗しない処理フローをメモ。
「そんなの当然じゃね？」ってものだと思うけど、実際にやる時になるとその都度考えちゃったりするものなので・・・
テーブルリファクタリングフロー
- 新テーブル(群)の設計
- 過去からの移行のし易さや過度に先を見越した設計はゴミになるので今のあるべき形で設計する
- CRUDの[C]部分への新テーブルの組込み
- システムの該当データを作る部分に新テーブルへのinsert処理を組込む
- 旧テーブルへの処理はそのまま残す
- CRUDの[U]部分への新テーブルの組込み
- システムの該当データを作る部分に新テーブルへのupdate処理を組込む
- 旧テーブルへの処理はそのまま残す
- 尚、論理削除や業務的なデータ削除は 9.ではなく、ここで対応する
- 旧テーブルから新テーブルへのデータ移行
- 外部参照制約の張り替え
- 旧テーブル群自体や関連テーブルに付けられている外部参照制約を新テーブル側を参照させる様に張り替える
- CRUDの[R]部分を新テーブルを参照するように差し替える
- システムの該当データを参照する部分を新テーブルに向ける
- CRUDの[U]部分から旧テーブルへの処理を削除
- システムの該当データを更新する部分から旧テーブルへの処理を削除する
- 3.と同様、論理削除や業務的なデータ削除部分もここで対応する
- CRUDの[C]部分から旧テーブルへの処理を削除
- システムの該当データを登録する部分から旧テーブルへの処理を削除する
- CRUDの[D]部分への新テーブルの処理の追加及び旧テーブルの処理の削除
- システムの該当データを抹消する部分（ガーベージ）に新テーブルからの処理を追加する。また同時に旧テーブルからの処理を削除する
- 旧テーブルをリネームする
- 旧テーブルを削除前に寝かせる。障害を検知するための最後の猶予期間
- 旧テーブルを削除する
(補足)
各ステップで行うシステムの対応順序(1)
- 単独のプログラム（軽微なシェルや依存関係のない小さなバッチなど）
- コアになるプログラム
- 共通ライブラリなど
- データベースオブジェクト（PL/SQLなど）
各ステップで行うシステムの対応順序(2)
- 社内システム
- 公開システム
※ 影響範囲の小さなものから大きなものに広げていくだけ
ちなみに、工数的な問題で旧テーブルをViewにして残すことが行われることもあるけど、データ構造のリファクタでは__絶対やめた方がいい__です。問題を先送りにすることで、負の遺産の「負っぷり」がめちゃくちゃ大きくなります。
一時的にView化ってのはありだけど、スケジュール上の通過点としてじゃなきゃやっちゃダメです。後方互換性、ダメ、絶対。