Day5 後半
「条件で絞る」を体に染み込ませる
前半で、SELECT * と WHERE（=, >, <）の基本的な意味はつかめました。
後半では、同じ構文を「いろんな角度から何度も使う」ことで、頭ではなく反射で書けるレベルに近づけていきます。
もう一度だけ、全体の型を確認する
SELECT * FROM テーブル名
WHERE 条件;
この形は、今後ずっと使い続けます。
Day5 では「条件」の中身として =, >, < を使っていますが、ここに入るものが増えていくだけで、基本の骨格は変わりません。
例題1：年齢で絞り込むパターンを言葉で言えるようにする
users テーブルが次のような状態だとします。
id | name | age | email
---+------------+-----+----------------------
1 | 山田太郎 | 25 | taro@example.com
2 | 佐藤花子 | 19 | hanako@example.com
3 | 鈴木一郎 | 30 | ichiro@example.com
4 | 高橋健 | 22 | ken@example.com
ここから、いくつかの「よくある質問」を SQL に変換してみます。
「20歳以上のユーザーを全部見たい」
これは「age が 20 以上」という条件です。
Day5 では >= はまだ出していないので、「20より大きい」ではなく「20以上」としたい場合は、いったん > と < の感覚を固めるために、こう考えてください。
「20歳より上」なら age > 20。
「20歳未満」なら age < 20。
今は >, < に慣れることを優先して、「以上」「以下」は Day6 以降に回しても構いません。
大事なのは、「列名 比較演算子 値」という形が自然に出てくることです。
例題2：IDでピンポイントに1件だけ取る
「ID が 3 のユーザーだけ見たい」
これは、= を使った最も典型的なパターンです。
SELECT * FROM users
WHERE id = 3;
結果は 1 行だけになります。
id | name | age | email
---+------------+-----+----------------------
3 | 鈴木一郎 | 30 | ichiro@example.com
ここで意識してほしいのは、「id は INTEGER だから、値はクォートしない」ということです。WHERE id = '3'; と書いても SQLite は動いてしまいますが、「数値なのに文字列っぽく書く」癖は、後々バグや脆弱性の温床になります。
例題3：名前で絞り込むときの“クォートの感覚”
「名前が ‘佐藤花子’ の人だけ見たい」
SELECT * FROM users
WHERE name = '佐藤花子';
ここでは、name が TEXT 型なので、値をシングルクォートで囲むのが必須です。
もしクォートを忘れてこう書くと、
WHERE name = 佐藤花子;
SQL は 佐藤花子 を「列名かキーワード」として解釈しようとしてエラーになります。
この「文字列は必ずクォート」というルールは、INSERT でも WHERE でもまったく同じです。
「まず SELECT *、次に WHERE」を実際の手順として定着させる
実際に手を動かすときは、次のような流れを毎回踏んでください。
まず、テーブルの中身を確認する。
SELECT * FROM users;
その結果を見ながら、「どの列を条件に使うか」「どんな値で絞るか」を決める。
たとえば、「age を見て、20より大きい人だけ欲しいな」と思ったら、こう書き足します。
SELECT * FROM users
WHERE age > 20;
この「全体を見る → 条件を付ける」という二段階は、SQL のデバッグでものすごく役に立ちます。
いきなり複雑な WHERE を書いて動かない、という沼にハマる前に、必ず一度 SELECT * を挟む癖をつけてください。
条件が間違っているときの“違和感”を大事にする
たとえば、次のように書いたとします。
SELECT * FROM users
WHERE age > 100;
結果が空になるか、ほとんど出てこないはずです。
このとき、「本当にそういう条件を指定したかったのか？」と自分に問い直す癖をつけてください。
逆に、こう書いたとします。
SELECT * FROM users
WHERE age < 100;
ほぼ全員が出てくるでしょう。
「絞り込みたいのに、ほとんど絞れていない」という違和感を覚えたら、条件の値や演算子を見直します。
この「結果を見て違和感を覚えたら、条件を疑う」という感覚は、セキュリティ的にも重要です。
意図しない大量データ取得は、そのまま情報漏洩やパフォーマンス問題につながるからです。
セキュリティの視点から見る「WHEREを書き忘れる怖さ」
もし管理ツールの中で、こう書くべきところを
SELECT * FROM users
WHERE id = 3;
うっかり WHERE を書き忘れて
SELECT * FROM users;
としてしまうと、全ユーザーの情報が一度に取得されます。
それがログに残ったり、画面に表示されたり、外部に送信されたりすると、それだけで重大な事故になり得ます。
だからこそ、「本当に全件必要か？」と自分に問いかける癖を、今のうちから持っておいてほしいです。SELECT * は学習では便利ですが、実務では慎重に使うものだ、という意識も少しずつ育てていきましょう。
小さな練習課題で締める
頭の中で、次の日本語を SQL に変換してみてください。
ID が 5 のユーザーだけを取り出したい。
年齢が 30 より大きいユーザーだけを取り出したい。
名前が ‘高橋健’ のユーザーだけを取り出したい。
全部、SELECT * FROM users に WHERE を足すだけで書けるはずです。
もしスラスラ出てこなければ、Day5 前半・後半の例を真似しながら、何度か書いてみてください。
Day5 後半のまとめ
SELECT * は「全件確認」のための基本動作だが、実務では乱用しない意識も大事。WHERE による絞り込みは、「列 比較演算子 値」という形を体で覚える。= はピンポイント指定、>, < は数値の範囲指定に使う。
結果を見て「多すぎる」「少なすぎる」と感じたら、条件を疑う癖をつけることが、品質とセキュリティの両方を守る。