前回の続き——読む側から、変える側へ
前回のL-07では、分けて保存した表をJOINで合わせて見る方法を学びました。これでリレーショナルの読み取り側は一通りそろいました。今回は、データを新しく足す、書き換える、消すという、状態そのものを変える操作に進みます。読み取りは失敗しても表示が乱れるだけですが、書き換えは失敗するとデータが壊れます。だからこの講義は、便利さより先に危険の見取り図を持つことを目的にします。
このスライドのポイント
- L-07: 分けて保存した表をJOINで合わせて「見る」方法を学んだ
- これでリレーショナルの読み取り側は一通りそろった
- 今回は状態そのものを変える操作（追加・変更・削除）に進む
- 読み取りの失敗は表示の乱れで済むが、書き換えの失敗はデータが壊れる
3つの文の定義
3つの文の役割を定義します。INSERTは、テーブルに新しい行を1件追加する文です。UPDATEは、すでにある行の値を書き換える文で、対象をWHEREで限定します。DELETEは、行を削除する文で、こちらも対象をWHEREで限定します。これらはD-05のHTTPメソッド、POST・PATCH・DELETEにほぼ対応し、J章で見たサーバーのハンドラーからDBMSへ発行されます。ここで最重要の注意です。UPDATEとDELETEは、WHEREを忘れると、テーブルの全行に作用します。
このスライドのポイント
- INSERT: テーブルに新しい行を1件追加する
- UPDATE: すでにある行の値を書き換える（WHEREで対象を限定）
- DELETE: 行を削除する（WHEREで対象を限定）
- D-05のHTTPメソッド（POST・PATCH・DELETE）にほぼ対応し、J章のハンドラーから発行される
- 最重要注意: UPDATEとDELETEはWHEREを忘れると全行に作用する
なぜWHEREを最初に警戒するのか
なぜこの危険を最初に強調するのか。WHEREを書き忘れたUPDATEやDELETEは、1件だけ直すつもりが全件を書き換え、全件を消してしまう、DB操作で最悪級の事故だからです。これはA-09で学んだ「元に戻せない変更」のSQL版そのものです。削除されたデータや上書きされた値は、履歴からコードを戻すようには戻せません。しかも、この文を書くのがAIであっても事故は起きます。AIもWHEREの付け忘れや条件の書き間違いをします。だからこそ、人間が実行前に立ち止まる工程が要ります。
このスライドのポイント
- WHERE忘れのUPDATE・DELETEは、1件のつもりが全件を書き換え・全削除する最悪級の事故
- A-09で学んだ「元に戻せない変更」のSQL版
- 削除・上書きされたデータは、コードのように履歴から戻せない
- 書くのがAIでも事故は起きる（AIもWHEREを付け忘れる・条件を書き間違える）
3文の作用とWHERE忘れ時の被害
3つの文を、作用とWHERE忘れ時の被害で並べて整理します。INSERTは行を1件足す文で、WHEREは持ちません。UPDATEは対象行の値を変え、WHEREを忘れると全行が書き換わります。DELETEは対象行を消し、WHEREを忘れると全行が消えます。危険度が最も高いのはDELETEです。実行の前に必ずWHEREの有無を確認し、A-09で学んだとおりバックアップの有無も人間が確かめてください。
このスライドのポイント
- INSERT: 行を1件足す。WHEREを持たない
- UPDATE: 対象行の値を変える。WHERE忘れ→全行が書き換わる
- DELETE: 対象行を消す。WHERE忘れ→全行が消える
- 危険度が最も高いのはDELETE。実行前に必ずWHEREの有無を確認し、バックアップの有無も人間が確かめる（A-09）
事故の起き方と、安全な直し方
具体例で危険の起き方を見ます。経費1件を承認するつもりで、UPDATE expenses SET approved = true; とだけ書いたとします。WHEREがありません。この文は、expensesの全経費を承認済みに変えてしまいます。正しい進め方は、まず変えたい行をSELECTで表示し、対象が本当にその1件かを目で確認します。そのうえで、確認に使ったのと同じWHERE条件をUPDATEに付けて実行します。SELECTで確かめてから同じ条件で変える。この2段構えが事故を防ぐ基本手順です。
このスライドのポイント
- 事故例: 経費1件を承認するつもりで
UPDATE expenses SET approved = true;（WHERE無し）→ 全経費が承認済みに - 安全手順: まずSELECTで対象を表示して1件か確認 → 同じWHERE条件でUPDATEを実行
- 「SELECTで確かめてから、同じ条件で変える」の2段構え
技術サンプル: UPDATEの安全2段手順
スライドのサンプルは、UPDATEを安全に行う2段手順です。種別はsql、目的は変更の前に対象を必ず確かめることです。①では id = 42 という条件で対象の行をSELECTし、承認しようとしているのがその1件かを確認します。②では、まったく同じ WHERE id = 42 を付けてUPDATEします。読みどころは、①と②のWHEREが完全に同じである点です。この操作はrisk: highです。実行前にバックアップの有無を確認し、失敗しても戻せるよう、次回L-09のトランザクションで囲む備えも覚えておいてください。
混同しやすい点——「1行のつもり」と「WHEREが緩い」
混同しやすいのは、「1行を変えているつもり」と「WHEREが緩くて複数行に当たっている」状態です。id = 42 のように主キーで指定すれば対象は1行に定まります。しかし、名前や日付の範囲でWHEREを書くと、思ったより多くの行に当たることがあります。同姓同名の社員、想定より広い日付範囲などです。ですから、id指定以外のWHEREを使うときは、実行の前に対象が何行かを必ずSELECTで数えて確かめてください。
このスライドのポイント
- 「1行を変えているつもり」 vs 「WHEREが緩くて複数行に当たっている」
id = 42のように主キー指定なら対象は1行に定まる- 名前や日付範囲のWHEREは、想定より多くの行に当たることがある（同姓同名、広すぎる日付範囲）
- id指定以外のWHEREを使うときは、実行前に対象が何行かをSELECTで数えて確認する
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIに変更系のSQLを作らせたら、いきなり実行せず、まず同じ条件のSELECTで件数を確かめることを定型手順にしてください。AIへの質問例はこうです。「このUPDATEやDELETEのWHERE条件で、何行が対象になりますか」。そして、本番環境での直接実行は、B-06とA-09の原則どおり一段止まります。件数の確認、バックアップの確認、そのうえで実行、の順番を崩さないことが安全の要です。
このスライドのポイント
- AIに変更系SQLを作らせたら、いきなり実行せず、まず同じ条件のSELECTで件数を確認する（定型手順）
- AIへの質問例: 「このUPDATE・DELETEのWHERE条件で、何行が対象になりますか」
- 本番環境での直接実行は、B-06・A-09の原則どおり一段止まる
- 「件数確認 → バックアップ確認 → 実行」の順番を崩さない
まとめと一問一答
最後に一問一答です。問題。WHEREのないDELETEは、何行を消すでしょうか。（間）答えは、全行です。テーブルの全データが消える、最悪級の事故になります。30秒まとめです。データを変える文はINSERT・UPDATE・DELETEの3つ。UPDATEとDELETEはWHEREで対象を限定し、忘れると全行に作用します。だから、同じ条件のSELECTで先に確認してから変える。次回L-09では、事故を仕組みの側から防ぐ制約とトランザクションを学びます。関連資料は「DB設計チェックリスト50」「バックアップと復旧入門」です。
このスライドのポイント
- 一問一答: 「WHEREのないDELETEは何行を消す？」→ 答: 全行（テーブルの全データ。最悪級の事故）
- 30秒まとめ: 変える文はINSERT・UPDATE・DELETE。UPDATEとDELETEはWHEREで対象を限定し、忘れると全行に作用
- 事故防止: 同条件のSELECTで先に確認 → 同じWHEREで変える
- 次回L-09: 事故を仕組みで防ぐ「制約・トランザクション」へ
- 関連資料: 「DB設計チェックリスト50」「バックアップと復旧入門」
