Day7 後半
1つのテーブルで CRUD を一周させて「できる感覚」をつかむ
前半で、タスク管理用の tasks テーブルを自分で設計し、CREATE TABLE まで行きました。
後半では、このテーブルに対して CRUD（Create / Read / Update / Delete）を一通り実行 していきます。
ここまで来ると、「SQL を勉強している人」から「SQL を使ってデータを回せる人」に一段階進みます。
Create：タスクを登録する（INSERT）
まずは、タスクをいくつか登録してみます。
前半で作ったテーブルはこうでした。
CREATE TABLE tasks (
id INTEGER,
title TEXT,
detail TEXT,
done INTEGER
);
ここに、3件のタスクを入れてみます。
INSERT INTO tasks (id, title, detail, done)
VALUES
(1, '買い物に行く', '牛乳と卵を買う', 0),
(2, 'メール返信', 'クライアントAに見積もりを送る', 0),
(3, '勉強', 'SQLiteのDay7をやる', 0);
ここでのポイントは二つです。done をすべて 0（未完了）で入れていること。id, title, detail, done の列順と、VALUES の値の順番をきっちり合わせていること。
「まずは全部未完了で登録して、あとから完了に更新する」という流れが、このあと Update の練習にもつながります。
Read：登録したタスクを確認する（SELECT）
タスクを入れたら、必ず「本当に入ったか」を確認します。
これは学習でも実務でも、絶対に外してはいけない習慣です。
SELECT * FROM tasks;
想定どおりなら、次のような結果になります。
id | title | detail | done
---+------------- +----------------------------+-----
1 | 買い物に行く | 牛乳と卵を買う | 0
2 | メール返信 | クライアントAに見積もりを送る | 0
3 | 勉強 | SQLiteのDay7をやる | 0
ここで「列の並び」「値の入り方」「done が全部 0 であること」を目で確認します。
もしおかしければ、この段階で INSERT を見直せます。
この「書いたら必ず読む（確認する）」という往復が、データの品質とセキュリティの両方を守ります。
Update：タスクの状態を更新する（UPDATE）
次に、「タスクが終わった」という状況を SQL で表現してみます。
ここでは、「id が 1 のタスク（買い物に行く）が完了した」とします。
done を 0 から 1 に更新します。
UPDATE tasks
SET done = 1
WHERE id = 1;
意味は、「tasks テーブルの中で、id が 1 の行の done を 1 に変えてください」です。
ここで重要なのは、WHERE を必ず付けることです。
もし WHERE を付け忘れてこう書くと、
UPDATE tasks
SET done = 1;
全てのタスクの done が 1 になってしまいます。
これは、実務では普通に事故レベルです。
更新後、必ず確認します。
SELECT * FROM tasks;
結果はこうなっているはずです。
id | title | detail | done
---+------------- +----------------------------+-----
1 | 買い物に行く | 牛乳と卵を買う | 1
2 | メール返信 | クライアントAに見積もりを送る | 0
3 | 勉強 | SQLiteのDay7をやる | 0
「1件だけ変わっている」ことを確認できたら、UPDATE が正しく書けている証拠です。
Delete：タスクを削除する（DELETE）
最後に、「終わったタスクを一覧から消す」という操作をやってみます。
ここでは、「id が 1 のタスクを削除する」とします。
DELETE FROM tasks
WHERE id = 1;
意味は、「tasks テーブルから、id が 1 の行を削除してください」です。
これも UPDATE と同じく、WHERE が命綱です。
WHERE を付け忘れてこう書くと、
DELETE FROM tasks;
全件削除になります。
これは、バックアップがなければ取り返しがつきません。
削除後、また確認します。
SELECT * FROM tasks;
結果はこうなります。
id | title | detail | done
---+------------- +----------------------------+-----
2 | メール返信 | クライアントAに見積もりを送る | 0
3 | 勉強 | SQLiteのDay7をやる | 0
id = 1 の行だけが消えていることを確認できれば、DELETE も成功です。
CRUD を一周したときに見える「データのライフサイクル」
ここまでで、1つのタスクがたどる流れを SQL で表現できました。
テーブルが作られる（CREATE TABLE）。
タスクが登録される（INSERT）。
タスクが参照される（SELECT）。
タスクの状態が変わる（UPDATE）。
タスクが削除される（DELETE）。
これはそのまま、「現実世界の情報がシステムの中でどう生まれ、どう変化し、どう消えていくか」というライフサイクルです。
SQL は、そのライフサイクルを操作するための言語だ、という感覚を持ってもらえたら Day7 の目的は達成です。
セキュリティの視点から見る CRUD の注意点
CRUD の中で、特に事故につながりやすいのは UPDATE と DELETE です。
どちらも WHERE を書き忘れると「全件」に作用してしまいます。
だからこそ、次のような癖をつけると安全度が一気に上がります。
まず、対象を SELECT で確認する。
SELECT * FROM tasks
WHERE id = 1;
「本当にこの行だけを変えたい／消したい」と確認してから、同じ WHERE を使って UPDATE や DELETE を実行する。
UPDATE tasks
SET done = 1
WHERE id = 1;
DELETE FROM tasks
WHERE id = 1;
この「先に SELECT で確認してから書き換える」という二段階は、プロでも普通にやっている防御策です。
Day7 後半のまとめ
INSERT でタスクを登録し、SELECT で確認することで「Create / Read」を体感した。UPDATE で特定の行の done を 0→1 に変え、「状態が変わる」ことを表現した。DELETE で特定の行を消し、「データがライフサイクルの終わりを迎える」ことを体感した。UPDATE / DELETE では、WHERE の付け忘れが致命傷になるため、「先に SELECT で確認する」癖が重要になる。
ここまでできていれば、「小さなテーブルを自分で設計して CRUD を一通り回せる人」になっています。
この土台の上に、次のステップとして「主キー」「制約」「複数テーブルの結合」などを積み上げていくと、実務レベルの SQL に自然と近づいていきます。
