Day24 後半のゴール
「顧客を“探せて”“直せて”“消しすぎない”ところまで持っていく」
前半で、customers テーブルという土台はできました。
後半ではいよいよ「実際に使う」側に踏み込みます。
名前やメールアドレスで検索する
特定の顧客の情報を更新する
退会扱いにする（削除ではなく“状態を変える”）
この3つを軸に、検索・更新の基本パターンを固めていきます。
同時に、「消し方を間違えると痛い目を見る」という話も、セキュリティと絡めて押さえます。
顧客を検索する基本パターン
「id でピンポイント」「名前であいまい」「メールで一意」
前半で作ったテーブルを思い出します。
CREATE TABLE customers (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
email TEXT NOT NULL UNIQUE,
phone TEXT,
registered_at TEXT NOT NULL,
status INTEGER NOT NULL DEFAULT 1
);
検索の基本は「何で探すか」を決めることです。
id で探す場合は、ピンポイント検索になります。
SELECT *
FROM customers
WHERE id = 1;
これは「絶対に 1 件（か 0 件）」という前提で使えるので、
アプリの内部処理でよく使う形です。
名前で探す場合は、部分一致が欲しくなります。
SELECT *
FROM customers
WHERE name LIKE '%山田%';
LIKE '%山田%' は、「名前のどこかに『山田』を含む」顧客を探します。
フルネームが分からないときや、あいまい検索をしたい画面でよく使う形です。
メールアドレスで探す場合は、一意であることを前提にできます。
SELECT *
FROM customers
WHERE email = 'taro@example.com';
email に UNIQUE 制約を付けているので、
このクエリは「0 件か 1 件」のどちらかになります。
ログイン処理や、パスワードリセットの対象を特定するときなどに使うイメージです。
ここでのポイントは、「カラムごとに役割が違う」という感覚です。
id は内部用の絶対キー、email は外向きだけど一意、name はあいまい検索向き。
この役割分担を意識しておくと、検索クエリの設計がぶれにくくなります。
ステータスを条件にした検索
「有効な顧客だけ」「退会済みだけ」を簡単に取れるようにする
status カラムを用意したのは、「状態で絞れるようにするため」でした。
例えば、1=有効、0=退会と決めているとします。
有効な顧客だけを一覧したい場合は、こう書けます。
SELECT *
FROM customers
WHERE status = 1;
逆に、退会済みだけを確認したい場合はこうです。
SELECT *
FROM customers
WHERE status = 0;
さらに条件を組み合わせると、「有効な顧客の中から、名前に『山田』を含む人」も簡単に書けます。
SELECT *
FROM customers
WHERE status = 1
AND name LIKE '%山田%';
ここで大事なのは、「退会＝DELETE しない」という設計です。
物理削除（DELETE）してしまうと、「いつ退会したか」「過去にどんな取引があったか」が追えなくなります。status のようなフラグで「今は使えないが、履歴としては残す」という形にしておくと、
後からの調査やトラブル対応が圧倒的にやりやすくなります。
顧客情報を更新する基本パターン
「id で特定して、変えたいカラムだけ UPDATE する」
更新の基本は UPDATE です。
まずは、メールアドレスを変更する例から見てみます。
UPDATE customers
SET email = 'new-taro@example.com'
WHERE id = 1;
ここで重要なのは、必ず WHERE で対象を絞ることです。WHERE を書き忘れると、全顧客のメールアドレスが同じ値に書き換わる、という悪夢が起きます。
複数のカラムを同時に変えることもできます。
UPDATE customers
SET
name = '山田太郎（改名後）',
phone = '090-9999-8888'
WHERE id = 1;
SET の中でカンマ区切りで並べるだけです。
「変えたいところだけ書けばよい」というのが UPDATE の基本です。
メールアドレスには UNIQUE 制約があるので、
既に他の顧客が使っているメールアドレスに変更しようとするとエラーになります。
これは「うっかり同じメールアドレスを二重登録する」事故を防ぐためのガードです。
退会処理をどう実装するか
「DELETE ではなく、status を変える“論理削除”」
顧客を「消す」処理をどうするかは、実務でもよく悩むポイントです。
ここでは、物理削除（DELETE）ではなく、論理削除（ステータス変更）で考えます。
退会させるときは、こう書けます。
UPDATE customers
SET status = 0
WHERE id = 2;
これで、id=2 の顧客は「退会済み」という扱いになります。
一覧画面では WHERE status = 1 を付けておけば、自然と表示されなくなります。
一方、物理削除はこうです。
DELETE FROM customers
WHERE id = 2;
この場合、その顧客の行は完全に消えます。
「本当に二度と必要ない」「関連データも全部消す」と決めているならアリですが、
多くの業務システムでは、後から履歴を追いたくなることがほとんどです。
セキュリティと監査の観点からも、
「誰がいつ退会したか」「退会前にどんな状態だったか」を追えるようにしておく方が安全です。
その意味で、顧客管理では論理削除（status フラグ）を基本にしておくのが無難です。
更新時に気をつけるべきこと
「WHERE の条件」「制約エラー」「想定外の一括更新」
UPDATE は強力な分、ミスると被害も大きいです。
特に次の3つは、毎回意識してほしいポイントです。
1つ目は、WHERE を必ず付けること。
「とりあえず動くか試そう」と思って WHERE を外した UPDATE を打つと、
全行が書き換わります。これは本当にやりがちです。
2つ目は、制約エラーを前提にすること。
メールアドレスの UNIQUE や、NOT NULL のカラムに NULL を入れようとすると、
UPDATE でもエラーになります。
「エラーが出たらダメ」ではなく、「エラーが出ることで守られている」と捉えると、
制約を味方にできます。
3つ目は、「本当にその条件で合っているか」を確認すること。
例えば、WHERE email = 'taro@example.com' で更新する場合、
本当に 1 件だけなのか、事前に SELECT で確認してから UPDATE する癖をつけると安全です。
検索と更新を組み合わせた“よくある流れ”
「探す → 確認する → 直す → もう一度確認する」
実際の運用では、検索と更新はセットで使われます。
典型的な流れを一つイメージしてみましょう。
まず、対象の顧客を検索します。
SELECT *
FROM customers
WHERE email = 'taro@example.com';
結果を見て、「この人で間違いない」と確認します。
その上で、更新クエリを打ちます。
UPDATE customers
SET phone = '090-0000-0000'
WHERE email = 'taro@example.com';
そして、もう一度 SELECT して、本当に変わったかを確認します。
SELECT *
FROM customers
WHERE email = 'taro@example.com';
この「検索 → 更新 → 再検索」という三段構えは、
シンプルですが非常に大事な習慣です。
特に本番データを触るときは、
「いきなり UPDATE しない」「必ず結果を目で見る」を徹底すると、
事故の確率がかなり下がります。
Day24 後半のまとめ
customers テーブルに対して、id・name・email・status を使い分けて検索することで、「ピンポイント」「あいまい」「一意」「状態で絞る」といった基本パターンを押さえられる。
UPDATE は「変えたいカラムだけを SET し、必ず WHERE で対象を絞る」が鉄則で、メールアドレスの UNIQUE や NOT NULL 制約が“守りのガード”として働く。
顧客の「削除」は、DELETE ではなく status を変える論理削除にしておくと、履歴や監査の観点から安全で、後からのトラブル調査もしやすい。
検索 → 更新 → 再検索という三段階の流れを習慣にすると、「誰をどう変えたか」を自分の目で確認でき、想定外の一括更新や取り返しのつかないミスを避けやすくなる。
ここまでできれば、「顧客管理テーブルを自分で設計し、検索・更新まで一通り回せる人」です。
あとは、このパターンを少しずつ応用して、「住所テーブルを分ける」「注文テーブルと紐づける」など、現実のシステムに近づけていくステージに進めます。
