同じ空欄でも、取り込み先によって「変更しない」「既存値を消す」などの扱いが異なる可能性があります。空欄が安全だと決めつけず、更新の規則を先に確認します。本記事は特定のシステムの仕様を断定するものではありません。
入力と更新後を分けて考える
取り込み用ファイルが正しく見えても、既存の値がどう変わるかは別の問題です。新規登録と既存レコードの更新で動きが違う場合もあります。まずどちらの操作をするかを特定します。
決めておく対応表
| 取り込み側の状態 | 確認すべき更新規則 |
|---|---|
| 値が入っている | 置換するか、追加するか |
| 空欄になっている | 維持するか、消去するか |
| 列自体がない | 変更対象外か、エラーか |
| 削除用の指定がある | 指定の方法と権限 |
これは確認項目の例です。実際の取扱いは資料や小さな検証で確かめます。空欄と削除の意味を同じ記号へまとめないようにします。
作業前の依頼文
[対象項目]の空欄は、既存値を消す意図ではありません。取り込み先で空欄がどう扱われるかを確認してから実行してください。削除が必要な値は、別に承認した対象だけに限定してください。
このルールは運用例です。実際に削除したい場合は、どの項目を消すかを明記します。確認できない仕様を、希望した動きとして説明しません。
小さく確かめる
許可された検証用データで、値あり、空欄、列なしのケースを分けて試します。試した条件と結果を残し、本番でも同じ設定かを確認します。実データの一括更新を、挙動確認の代わりに行わないようにします。
実行後の照合
変更対象だけでなく、維持する予定だった値も確認します。元の値を保存していなければ、戻すための情報が足りない場合があります。復元方法を確認せず、いつでも元に戻せると約束しません。
意図を取り違える例
架空の例として、連絡先の更新だけをしたいファイルで、備考欄が空だったとします。空欄を削除と扱う仕様なら、既存の備考まで消える可能性があります。変更しない列を除けるか、空欄の挙動を設定できるかを調べ、実際に確認できた方法を選びます。希望する動作を書くだけでは設定は変わりません。

コメント