データ移行には移行ツールの開発が必須。
採番体系やデータ構造が新旧で違ってくると、仕様の定義に非常に苦労することになる。

移行ツールの種類

A) 既存ツール(プロダクト)の流用 – DBのGUI or CUIツールなど
B) 開発 – PGをガリガリ書く
C) SQLのみで済ませる
D) アプリ機能の改修 – 既存アプリ機能(マスタの一括アップロード機能など)を少し改修して利用する

移行ツールの要件

  • 性能が十分であること(移行時間内に実施できるかが重要)
  • 新システムとの整合性が保たれていること
  • アプリなどの取込機能ではじくべきイレギュラーなデータが入らないように注意する
  • イレギュラーデータ発生時に、何かしらの形で対応できること
  • イレギュラーデータが必ず発生する。それを念頭において計画を立てる必要あり
  • 移行ツールの動作環境
  • 十分なSPECがあること
  • セキュリティが担保されていること (← 本番データを扱うため)
  • 移行ツールの事前調査は必須 * ← これ大事。使えない時に痛い目を見るので非常に大事
  • 新システムでの初回バッチや初回業務に対して、仕込みの必要有無を決める

移行ツールの外部設計

  • データのキー項目を新旧で明らかにする
  • キー項目が異なると、重複データが発生する可能性あり
  • DBに対するI/Oを明確にする
  • どこまでが手順(手作業)で、どこまでが開発範囲かを明確にする
  • どの環境でどのように実施想定か明記する。ssh接続で本番にログインしてCUIツールにて実行。保守端末からGUIツールにて実行など
  • データの変換仕様を明確にする。文字からコードへの逆引き
  • 回答圧縮ツールや script言語を利用する場合、本番環境にインストールされているか?を要確認

作成時期

  • マスキングデータを必要とするタイミング(IT or ST or UAT)までに作成する。
  • ITの時点で出来上がっているのが理想的ではあるため、DBのスキーマ定義がほぼ固まってきた時点で、マッピング設計を始める。
  • もっと大まかな設計は早めに始める

注意

  • 開発期間はDBスキーマの変更が発生することが常である
  • アプリやバッチ起因で変更が発生することを必ずウォッチできる仕組みを作成する必要がある
  • このためには、移行で入れる先のテーブルを明確にしておき、予め周知を行う

確認ポイント

  • 先にデータが型の相関性(新旧システム間)をしっかりチェック
  • 旧システムのDB文字コード、新システムのDB文字コードを確認
  • ネットワーク転送量
  • データ量

落とし穴系

  • バイナリデータの移行が手間だったりする
  • データ型が異なる
  • 特に日付の型。文字列のフォーマットが異なるケースが多い。
  • NULLと空文字をきちんと移行しないと、アプリ側で死ぬかも

ちなみに

  • SQL Server / Sybase は ダブルクオートがついているファイルは、BULKインサートツールで対応していない仕様っぽい
  • 他のDBからcsvで抜いてくると苦労することに
  • shift-jisだと ファイル読み込み時に 5c問題「申」とかで泣ける。utf8に変換しつつ読み込む。文字化け注意。
  • 日付を表すデータ型が異なるケースが多い。12時30分45秒が、12.30.45 だったり、12:30:45 だったり。後ろの数桁が途切れたり。