データの追加・更新・削除（INSERT/UPDATE/DELETE）

• 日程: Day 2 / セッション 1
• 時間: 9:00-9:30
• 形式: 座学
• ゴール: INSERT、UPDATE、DELETE 各文の構文と「WHERE忘れ」の危険性を説明できる
• 学習形式: 対話型解説

Day1では「データを読む」練習をしました。SELECTでテーブルを覗き、WHEREで絞り、GROUP BYで集計する——ここまでは、いわば「図書館で本を借りて読む」段階です。今日からは、本棚に新しい本を並べたり、誤植を直したり、不要な本を捨てたりします。つまり、データを「書き換える」側に回ります。

ここで一つ問いかけです。「全社員の給与を間違って100円にしてしまった」——もしこれを朝イチで実行してしまったら、皆さんは午後をどう過ごすでしょうか？　今日のセッションは、そういう恐ろしい未来を回避するための話でもあります。

このセッションでは、データを操作する3兄弟「INSERT・UPDATE・DELETE」の使い方と、それぞれに潜む落とし穴を紹介します。

SQLには大きく分けて、データを「読む」SELECT系と、データを「動かす」INSERT/UPDATE/DELETE系があります。後者をまとめて DML（Data Manipulation Language） と呼びます。

SELECTは読むだけなので何度実行しても安全です。一方、INSERT/UPDATE/DELETEはデータそのものを変えるので、間違えると元には戻りません（後で学ぶROLLBACKを使わない限り）。

新しい部署「総務部」を作りたい、と仮定しましょう。

INSERT INTO departments (department_name, location)
VALUES ('総務部', '東京');

基本構文はこうです。

INSERT INTO テーブル名 (列1, 列2, ...)
VALUES (値1, 値2, ...);

複数行をまとめて入れることもできます。

INSERT INTO departments (department_name, location) VALUES
('総務部', '東京'),
('法務部', '大阪');

• 列名のリストと VALUES のリストは順番と個数を一致させる
• department_id のような SERIAL（自動採番）の列は省略してOK——勝手に番号が振られる
• 文字列はシングルクォート '、数値はそのまま

「列名リストを省略してもいい」というルールもありますが、これは新人時代の罠です。INSERT INTO departments VALUES ('東京', '総務部'); のように順番を逆にして「東京という名前の、総務部にある部署」が爆誕したという珍事は、現場では年に1回くらい聞きます。列名を書くのは、未来の自分への手紙だと思ってください。

山田太郎さん（employee_id = 1）の給与を 45万 → 50万 に上げる場合。

UPDATE employees
SET salary = 500000
WHERE employee_id = 1;

基本構文はこうです。

UPDATE テーブル名
SET 列1 = 新しい値1, 列2 = 新しい値2
WHERE 更新したい行の条件;

複数列を一度に更新することもできます。

UPDATE employees
SET salary = 500000, department_id = 2
WHERE employee_id = 1;

• SET で「何を変えるか」、WHERE で「どの行を変えるか」
• WHEREを忘れると全行が更新される——これが今日一番大事な話です

ある先輩エンジニアが、本番DBで UPDATE employees SET salary = 100; と打って Enter を押してしまったそうです（WHEREを忘れた）。気づいたときには遅し、全社員10,000人の給与レコードが一律100円に。幸いその会社は毎晩バックアップを取っていたので半日で復旧しましたが、その先輩は1か月「100円さん」と呼ばれ続けたとか。皆さんは「100円さん」にならないでください。

テスト用に作った行（例：employee_id = 99）を消す場合。

DELETE FROM employees
WHERE employee_id = 99;

基本構文。

DELETE FROM テーブル名
WHERE 削除したい行の条件;

• DELETE FROM のあとはテーブル名のみ（列名は書かない。行ごと消えるので）
• WHERE を忘れると全行が消える。UPDATE以上に危険
• 外部キー制約のある行（例：注文がある顧客）は、関連も考えないと消せない

削除する前に、必ず SELECT で「これから何を消すのか」を確認する。

これは現場の鉄則です。具体的には次の3ステップで進めます。

1. まず SELECT * FROM テーブル WHERE 条件; で対象行を見る
2. 「この行たちを消す／更新する」と納得できたら、SELECT を DELETE や UPDATE に書き換える
3. 不安なときは BEGIN; でトランザクションを開始し、ROLLBACK; で取り消せるようにする（次セッションで実演します）

たとえるなら、家の鍵を壊す前に「本当にこれは要らない鍵か？」と3回確認するイメージです。SQLは「Enter キーを押した瞬間」が壊し時です。

• 「UPDATE文でWHERE句を忘れた場合、PostgreSQLは警告を出してくれる？」
• 「DELETE と TRUNCATE の違いを教えて。どう使い分ける？」
• 「INSERTで department_id を書かなくていいのはなぜ？ SERIAL型の仕組みを教えて」

INSERT は追加、UPDATE は更新、DELETE は削除——これがDMLの3兄弟です。構文の暗記より重要なのは、**「WHEREを忘れない」「実行前にSELECTで確認する」**という2つの習慣です。

次のセッションでは、実際にこの3つの文をsandbox環境で動かします。安全装置として BEGIN/ROLLBACK も先に教えるので、思い切って試せるはずです。

• INSERT文の構文を、列名と値の対応を意識して説明できますか？
• UPDATE文でWHERE句を書き忘れると何が起きますか？
• 危ない操作を実行する前にやるべき「確認の3ステップ」は何ですか？

• 参考リンク: PostgreSQL公式: INSERT / UPDATE / DELETE
• 発展課題: 自分の身の回り（学校のクラス名簿、家計簿、推しの推し活リスト等）で「INSERT/UPDATE/DELETE」しそうな場面を3つずつ挙げてみる