💽

データ修正で気を付けているコト・運用フローについて

2024/03/31に公開

はじめに

クライアントからシステムの画面上から更新・修正できないデータの修正依頼があり、DBのデータを直接修正することがある。
本来、データ修正は積極的に行うべきコトではないが、ユーザーの想定外の操作等でイレギュラーなデータが登録されてしまうこともあるため、どうしても修正する必要がある場面もある。
本番データは慎重に扱う必要があるため、運用フローと各フローで注意すべき点をまとめる。

1. 本当に直接修正すべきデータか確認

前述した通り、本来データ直接修正は行いたくない(べきではない)ので、主に以下項目について確認し、本当に直接修正すべきか確認する。

  • クライアントの勘違いではないか?(仕様の勘違いや実はクライアント側で修正ができる等)
  • システムの不具合ではないか?
  • 修正する必要がないデータではないか?(修正しなくても実害がないデータ等)
  • 新規登録した方が良いデータではないか?(修正ではなく、別途登録しなおした方が良いケース等)

ある意味ここの判断が1番重要だと思っていて、自分の作業が不要になりクライアントもデータ修正を待つ必要がなくなる。

2. 修正SQL作成

修正が必要と判断した場合、修正用SQLを作成する。
SQL作成にあたり、注意点等を以下にまとめる。(クエリのフォーマットはチームで統一した方がよいと思う。)
実行するSQLが意図した修正になっているか、テスト環境等で入念にテストをする。

BEGIN; // トランザクション開始

-- 修正データを確認
SELECT id, name, age FROM users WHERE id = 1;
+-----+--------+-----+
| id  | name   | age |
+-----+--------+-----+
|  1  | テスト   | 20  |
+-----+--------+-----+

SELECT id, name, age FROM users WHERE id = 2;
+-----+---------+-----+
| id  | name    | age |
+-----+---------+-----+
|  2  | テスト2   | 30  |
+-----+---------+-----+

-- データ更新
SELECT id, name, age FROM users WHERE id = 1; // 更新レコード・カラムをSELECTする。
UPDATE users SET age = 30 WHERE id = 1 LIMIT 1; // WHERE句は極力PKで指定する。LIMITをつける。

-- 修正内容確認
// UPDATE文前のSELECT文を再度実行し、修正内容を確認(↑コマンドを2回押してSELECT文を表示)

-- データ削除
SELECT * FROM users WHERE id = 2; // 削除レコードをSELECTする。
DELETE FROM users WHERE id = 2 LIMIT 1; // WHERE句は極力PKで指定する。LIMITをつける。

-- 削除内容確認
// DELETE文前のSELECT文を再度実行し、修正内容を確認(↑コマンドを2回押してSELECT文を表示)

COMMIT; // トランザクション終了(修正結果が想定通りの場合のみ)

3. 第三者のレビュー・承認を得る

作成したSQLにミス等がないか第三者にレビューしてもらい、承認を得る。

4. 修正実行・確認

SQLを実行し、意図した修正となっているか最終確認。

5. 作業ログの保存

万が一データ復旧に対応できるように、SQLの実行履歴をドキュメント等に保存する。

さいごに

現状、記載した注意点・フローを徹底しているためか大きな失敗等は発生せず作業できている。
定期的に発生するデータ修正項目については、

  • システム管理者限定の修正ツール実装
  • 根本原因を解決するようシステム改修

等を行い、データ直接修正を件数を減らすよう努力するべきだと思う。

参考

http://www8.plala.or.jp/a_ITC/legend_02Direct_Data_Rectification_Control.htm
https://qiita.com/MandoNarin/items/68d115322af07ac3971e

GitHubで編集を提案

Discussion