Day24 前半のゴール
「小さくても“ちゃんとした顧客管理テーブル”を自分で設計して作る」
ここからは「実践編」です。
Day24 のテーマは、ミニ課題としての 顧客管理テーブル。
前半では、次のところまでを目標にします。
顧客管理テーブルにどんな項目が必要かを自分で考える
SQLite で CREATE TABLE を書いて、テーブルを作る
サンプルデータを INSERT して、SELECT で中身を確認する
検索や更新の具体的なクエリは後半に回して、
まずは「土台となるテーブル設計」をしっかり固めます。
ここでのポイントは、
「なんとなくカラムを並べる」のではなく、
これまで学んだ PRIMARY KEY / NOT NULL / UNIQUE などを意識して
“ちゃんとした顧客テーブル”を設計することです。
顧客管理テーブルに何を入れるかを決める
「最低限の情報＋識別子＋連絡先」
まずは、どんな情報を持たせるかを決めます。
今回はシンプルな顧客管理を想定して、次のような項目を考えます。
顧客を一意に識別するための ID
顧客名（会社名でも個人名でもよい）
メールアドレス
電話番号（あれば）
登録日（いつこの顧客を登録したか）
ステータス（有効／退会などを表すフラグ）
ここで大事なのは、「ID を必ず用意する」ことです。
名前やメールアドレスは変わる可能性がありますが、
ID は一度決めたら変えない“軸”として扱えます。
また、メールアドレスは
「同じアドレスを複数の顧客に使わせない」
というルールにしたければ、UNIQUE 制約を付ける候補になります。
カラムと型・制約を決める
「PRIMARY KEY / NOT NULL / UNIQUE をどう使うか」
さっきの項目を、SQLite のカラム定義に落としていきます。
顧客 ID
型は INTEGER、PRIMARY KEY。
SQLite では INTEGER PRIMARY KEY にすると、自動採番（オートインクリメント的な動き）になります。
顧客名
型は TEXT。
必須にしたいので NOT NULL を付けます。
メールアドレス
型は TEXT。
必須にするなら NOT NULL、
さらに「同じメールアドレスは 1 人だけ」にしたいなら UNIQUE を付けます。
電話番号
型は TEXT。
任意項目なら制約なしでもよいですが、
「空でもいいが、入っていれば文字列」という扱いで十分です。
登録日
型は TEXT か INTEGER。
SQLite には日付専用型はないので、TEXT で YYYY-MM-DD 形式を入れる、
または UNIX 時刻を INTEGER で入れる、などの方針を決めます。
ここでは分かりやすく TEXT にします。
ステータス
型は INTEGER。
例えば 1=有効、0=退会、のように決めておくと扱いやすいです。
必須にしたいので NOT NULL を付け、デフォルト値を 1（有効）にしておくのもよくあるパターンです。
ここでの重要ポイントは、
「どのカラムを必須にするか」「どのカラムを一意にするか」を
ちゃんと意識して決めることです。
顧客管理テーブルの CREATE TABLE を書く
「制約をきちんと付けた定義にする」
今までの検討を踏まえて、実際の SQL を書いてみます。
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 INTEGER PRIMARY KEY
顧客を一意に識別する ID。
SQLite では自動的に 1, 2, 3… と増えていきます。
name TEXT NOT NULL
顧客名。空は許さない、という意思表示です。
email TEXT NOT NULL UNIQUE
メールアドレス。必須かつ一意。
同じメールアドレスで 2 人目を登録しようとするとエラーになります。
phone TEXT
電話番号。任意項目なので制約なし。
registered_at TEXT NOT NULL
登録日。'2025-05-02' のような文字列で入れる想定。
必須にしておくと、「いつ登録された顧客か」が必ず分かります。
status INTEGER NOT NULL DEFAULT 1
ステータス。1=有効、0=退会、などと決めておく。DEFAULT 1 により、INSERT 時に省略すると自動的に 1 が入ります。
ここまでで、
「最低限ちゃんとしている顧客管理テーブル」ができました。
サンプルデータを INSERT してみる
「制約が効いているかも体で感じる」
実際に何件かデータを入れてみます。
INSERT INTO customers (name, email, phone, registered_at)
VALUES
('山田太郎', 'taro@example.com', '090-1111-2222', '2025-05-01'),
('佐藤花子', 'hanako@example.com', NULL, '2025-05-02'),
('鈴木一郎', 'ichiro@example.com', '03-1234-5678', '2025-05-03');
id と status は省略していますが、id は自動採番、status は DEFAULT 1 が入るので問題ありません。
中身を確認してみます。
SELECT * FROM customers;
イメージとしては、こんな結果になります。
id | name | email | phone | registered_at | status
---+------------+--------------------+----------------+---------------+-------
1 | 山田太郎 | taro@example.com | 090-1111-2222 | 2025-05-01 | 1
2 | 佐藤花子 | hanako@example.com | NULL | 2025-05-02 | 1
3 | 鈴木一郎 | ichiro@example.com | 03-1234-5678 | 2025-05-03 | 1
ここで、わざと制約違反を試してみるのも良い練習です。
例えば、メールアドレスを省略してみるとどうなるか。
INSERT INTO customers (name, phone, registered_at)
VALUES ('テスト', '0120-000-000', '2025-05-04');
email は NOT NULL なので、
この INSERT はエラーになります。
また、既に存在するメールアドレスをもう一度入れてみるとどうなるか。
INSERT INTO customers (name, email, phone, registered_at)
VALUES ('ダブり', 'taro@example.com', '0120-999-999', '2025-05-05');
email は UNIQUE なので、
これもエラーになります。
この「エラーになる」という体験が、
制約がちゃんと効いていることの証拠です。
セキュリティの視点から見る顧客テーブル設計
「“必要以上の情報を持たない”ことも設計の一部」
顧客管理テーブルは、
個人情報を扱うことが多い領域です。
その意味で、
テーブル設計の段階から次のようなことを意識しておくと良いです。
本当に必要な情報だけを持つ
例えば、マイナンバーやクレジットカード番号のような
極めて機密性の高い情報は、
安易に顧客テーブルに入れない。
一意な識別子（id）をきちんと用意する
アプリ内部では極力 id で扱い、
メールアドレスなど“外に出る情報”を
内部のキーとして使い回さない。
メールアドレスを UNIQUE にするかどうかは、
「1人が複数アカウントを持てるか」などの仕様とセットで考える。
こういった視点は、
あとから「やっぱりこの情報はいらなかった」「漏れたらまずい」
と慌てないための保険になります。
Day24 前半のまとめ
顧客管理テーブルには、「一意な ID」「名前」「メールアドレス」「連絡先」「登録日」「ステータス」といった最低限の情報を整理して持たせる。INTEGER PRIMARY KEY で自動採番の ID を用意し、NOT NULL や UNIQUE を使って「必須」「一意」のルールをテーブル側に埋め込むことが重要。CREATE TABLE customers (...) を自分で書き、INSERT → SELECT で中身を確認しつつ、わざと制約違反を試して「どんなときにエラーになるか」を体で覚えると理解が深まる。
顧客テーブルは個人情報を扱うことが多いため、「本当に必要な情報だけを持つ」「内部キー（id）と外向き情報（メールなど）を分ける」といったセキュリティ視点も、設計段階から意識しておくと良い。
後半では、この customers テーブルを使って、
名前やメールアドレスで検索する SELECT
ステータスやメールアドレスを変更する UPDATE
退会扱いにする設計（物理削除か論理削除か）
といった「検索・更新まで実装」を一緒にやっていきます。
