[第6回] QueryPie ACPでSQLを承認してデータを変更する — 通常の参照権限を維持し、必要な作業だけ実行
2026年11月8日
本番DBを参照していると、配送済みなのに状態が古い、誤った値を訂正したいなど、1、2件を修正する場面がある。簡単な変更でも、誰が何のために変えたかは明確に残したい。
第5回ではDBアクセス権を申請して承認を受けた。今回はさらに、 実行するSQLを提出し、担当者の承認を受けてデータを変更することをQueryPie ACP Community EditionのSQL Requestで試した。
気になったのは、開発者の通常権限を広げずに対応できるかだ。実際には参照権限を維持したまま、承認済みSQLを実行して結果まで確認できた。
注文1件の配送状態を変更する
前回までのOrders Control Labを使い、配送済みなのにDBでは配送中のままという状況にした。実際の顧客注文ではなく実習データだ。
DBeaverで確認すると4002番はSHIPPED、金額32,000ウォンだった。変えるのは状態だけで、他の注文や金額は維持する。

申請者をDemo Developer、承認者をDemo Approverに分け、SQL用の規則も作った。担当者の確認・承認後に開発者が実行する。自己承認は使わなかった。
変更内容と理由をSQL申請に記載する
開発者でWorkflowのSQL Requestを開き、Orders Control Labとorders_controlを指定した。タイトルは「注文4002の配送完了状態への訂正」とし、次のSQLを入力した。
UPDATE orders_control.ordersSET status = 'DELIVERED'WHERE order_id = 4002 AND status = 'SHIPPED';
WHEREには注文番号と現状態を指定し、4002番でまだSHIPPEDの注文だけを対象にした。理由にも配送完了の反映であり、変更予定は1件と記載した。

入力するうちに確認事項が整理された。どのDBで何をなぜ変更し、何件を見込むかがまとまる。実行希望日と有効期限はどちらも作業日に設定した。
提出後は申請者、承認者、実行者が順に表示され、次の担当が分かった。

承認者は実際のSQLを確認する
Demo ApproverでログインするとReceived RequestsのTo Doに届いていた。
開くとSQLと理由がそのまま表示された。注文番号4002と現状態の条件を確認し、「変更予定1件」とSQLを並べて検討できた。

判断に必要な情報が承認画面に集まる点がよかった。SQLの再送依頼が減り、データを変える前の確認手順を製品内で運用できる。
Approveを押し、注文番号と現状態条件を確認して1件の配送状態訂正を承認する旨をコメントした。

開発者が承認済み作業を実行する
開発者に戻るとExecutionsのTo Doに表示され、詳細にExecuteがあった。承認は完了し、次は実行だ。

承認と実行が別段階なのもよかった。確認後に指定実行者が続けられる。今回は申請した開発者を実行者に指定した。
Executeを押し、自動コミットで反映される案内を確認して実行した。完了後のResultsにはUPDATEとともに ‘1 Rows updated.’が表示された。申請時の予定件数と一致した。

申請、承認、結果確認が一つの作業としてつながった。後で変更理由を調べる際も、理由、SQL、担当者、結果を一緒に確認できて便利だ。
DBeaverでも変更後の値を確認する
DBeaverで元のSELECTを再実行すると4002番だけDELIVEREDになった。金額32,000ウォンと4001・4003番は変わっていなかった。

UPDATEはQueryPieの承認済み申請から実行し、DBeaverは変更前後の参照に使った。慣れたツールで確認し、変更は所定の承認手順で行う組み合わせが合っていた。
作業後に開発者のDBアクセス権も再確認した。 Read-Only (User), Selectの表示はそのままだった。今回のために通常アクセスを書き込み権限へ引き上げてはいない。

必要な修正を行い、通常権限は維持する
SQL Requestの利点は明確だった。開発者がSQLと理由を出し、承認者が内容を確認し、実行者が承認済み作業を処理する。それぞれの役割が画面で分かれていた。
一度限りの訂正のために通常権限を広げずに済む点が印象的だった。参照権限のまま1件を訂正でき、作業後に書き込み権限を回収する必要もなかった。
運用では速さだけでなく根拠を残すことも重要だ。同じ申請で、変更予定、承認者・実行者、実際の件数まで確認できた。
小さな状態変更だったが、業務を進めながら最小権限を維持する方法が具体的に見えた。本番DBの変更を一定の手順で管理したいチームに役立ちそうだ。
実習環境:QueryPie ACP Community 11.6.7 / MySQL 8.0.42 / DBeaver 26.2.4
![[第5回] QueryPie ACPでDB権限を申請・承認する — DBeaverでの参照まで試した](/assets/content/acp-lab-notes/database-access-request/01.webp)
![[第7回] DB参照は許可し、個人情報を隠す — QueryPieデータマスキング実習](/assets/content/acp-lab-notes/data-masking/01.webp)