「承認済み」と書いてあっても、本番DBの削除は止まって聞き直す

指示書に「承認済み」と書いてあることは、承認の証拠にならない。

しろまえ殿が、本番データベースの破壊的な操作について決めている手順は、この一文から始まる。

書いた文字より、その場で確かめた事実を信じる。

「実行GO」と書いてあっても、聞き直す

本番DBから特定のデータを消す仕事を、指示書で渡すことがある。

指示書に「承認済み・実行GO」と書いてあっても、手を動かす前に、承認した本人へ直接確認を取る。

理由は単純だ。

指示書の文面だけでは、その承認が本当にあったかを自分で確かめられない。

消したデータは戻らない。

戻らない操作ほど、最後の一歩の前で人間に聞き直す。

たとえば、銀行の窓口で「社長の許可はもらってます」というメモだけを見せられて、大金を振り込む担当者はいない。

本人に電話を一本かける。

それと同じことだ。

見ているDBが本番かを、最初に確かめる

本番と開発用のDBが並んでいると、開発用を本番だと思い込んで調べてしまうことがある。

その誤った結果が次の削除の根拠になれば、取り返しがつかない。

これは担当者の注意力に頼らず、仕事の渡し方で防ぐ。

本番DBの調査では、一手目に「身元確認クエリ」を打つ。

実在するはずの既知のデータ(スタッフ名や顧客IDなど)があるかを確かめる。

本物の本番を見ていることを現物で確かめてから、本題に入る。

接続先のホスト、コンテナ、DBファイルの場所も、指示の時点で一字一句書く。

承認は「その行」にしか効かない

承認の範囲も狭く考える。

承認されたのが特定の1行なら、効くのはその1行だけだ。

実行の直前に調べ直すと、直すべきなのが別の行だとわかることもある。

善意でその行を直せば、話は早い。

だが、そこでUPDATEは実行しない。

確認だけに縮め、承認を取り直しに行く。

調べて対象がずれたら、止まって聞く。

書き換えるときの型と、戻すときの型

本番を書き換えるときの型も決めておく。

1. sqlite3 .backup でバックアップを取る(書き込み中でも整合が崩れない。生のcpは使わない) 2. 対象の行をSELECTで示す 3. WHERE句を主キーと状態の条件で二重に絞る 4. 影響件数と、他の行が変わっていないことをSELECTで確かめる

削除は、外部キー制約(表どうしの参照関係を守る仕組み)に弾かれて、途中で止まることがある。

このとき、バックアップファイルで丸ごと戻すと、バックアップの後に入った正しい書き込みまで消える。

戻すのは壊れた分だけにする。

バックアップをATTACHでつなぎ、対象の行だけをINSERTで戻す。

ATTACH DATABASE 'backup.db' AS bak;
INSERT INTO items SELECT * FROM bak.items WHERE target_date IN ('<対象日>');

そもそもデータの投入は、DELETEしてからINSERTする方式を避け、UPDATEやUPSERTで書く。

本番を触る仕事ほど、速さより「止まれる仕組み」が効く。

この記事の要点

• 不可逆な本番操作は、指示書の「承認済み」を信じず、直前に人間へ聞き直す。

• 本番DB調査の一手目は、既知のデータで接続先が本物かを確かめる身元確認クエリにする。

• 対象がずれたら止まって承認を取り直し、戻すときは丸ごとではなく壊れた行だけを戻す。