Day3 後半
「ちゃんと使えるテーブル」を自分で設計できるようになる
前半では、CREATE TABLE の基本形と、INTEGER / TEXT という二つのデータ型の意味を押さえました。
後半では、それを「実際に使える形」に落とし込んでいきます。
単にテーブルを作るだけでなく、「あとで困らない設計」に近づけることを意識します。
もう一度だけおさらいしつつ、少しだけ踏み込む
「列名＋型」の組み合わせがテーブルの“性格”を決める
CREATE TABLE の基本形は次の通りでした。
CREATE TABLE テーブル名 (
列名1 データ型,
列名2 データ型,
...
);
ここで決めているのは、次の二つだけです。
どんな名前の列を持つか。
その列にどんな種類のデータを入れるか。
たったこれだけですが、この段階でテーブルの“性格”はほぼ決まります。
だからこそ、INTEGER と TEXT をどう使い分けるかがとても重要になります。
例題1：ユーザー＋ログイン情報を考えてみる
「何を同じテーブルに入れて、何を分けるか」という視点
次のような情報を扱いたいとします。
ユーザーID
ユーザー名
メールアドレス
パスワード（ハッシュ化されたもの）
初心者がやりがちなのは、これらを全部1つのテーブルに詰め込むことです。
しかし、セキュリティと運用の観点からは、認証情報（パスワードハッシュ）は分けることが多いです。
ここでは、あえてシンプルに「まずは1テーブルで持つ」パターンを考え、そのうえで「なぜ分けたくなるのか」を感じてもらいます。
CREATE TABLE users (
id INTEGER,
name TEXT,
email TEXT,
password TEXT
);
ここでのポイントは、すべて INTEGER / TEXT で表現できていることです。
ID は整数、他は文字列。
Day3 の範囲では、これだけで十分に実用的なテーブルになります。
例題2：ブログ記事テーブルを設計する
「現実の情報」をどう列に落とし込むか
今度は、ブログ記事を管理する posts テーブルを考えてみます。
次のような情報を入れたいとします。
記事ID
タイトル
本文
著者名
これを CREATE TABLE にすると、次のようになります。
CREATE TABLE posts (
id INTEGER,
title TEXT,
body TEXT,
author TEXT
);
ここでも、INTEGER と TEXT だけで十分表現できています。
本文は長い文章になりますが、それでも TEXT で問題ありません。
SQLite の TEXT は、かなり長い文字列も扱えるからです。
実際にテーブルを作って、データを入れてみる流れ
「定義しただけ」で終わらせず、必ず一度は触ってみる
Day3 のゴールは、「CREATE TABLE を読める・書ける」だけでなく、「作ったテーブルに実際にデータを入れてみる」ところまで行くことです。
ここでは products テーブルを例に、一連の流れを確認します。
CREATE TABLE products (
id INTEGER,
name TEXT,
price INTEGER
);
テーブルを作ったら、データを1件入れてみます。
INSERT INTO products (id, name, price)
VALUES (1, 'ノートPC', 120000);
そして、ちゃんと入ったかを確認します。
SELECT * FROM products;
結果は次のようなイメージになります。
1 | ノートPC | 120000
この「定義 → 追加 → 確認」のサイクルを、自分の手で何度か回してみると、CREATE TABLE が一気に“自分のもの”になります。
よくあるつまずきポイントを先に潰しておく
「あとから列を増やしたくなったらどうするの？」という不安
初心者がよく不安になるのが、「あとから列を増やしたくなったらどうするのか」という点です。
結論から言うと、SQLite では ALTER TABLE という文で列を追加できます。
ALTER TABLE products
ADD COLUMN description TEXT;
Day3 の段階では、ALTER TABLE を深くやる必要はありませんが、「最初の設計で完璧を目指さなくていい」という安心感は持っておいてほしいです。
大事なのは、「今分かっている範囲で、INTEGER と TEXT を意識して設計してみる」ことです。
型を意識することは「未来の自分を助けること」
集計・検索・バリデーションのしやすさが変わる
たとえば、価格を TEXT にしてしまうと、次のような問題が起きます。
価格の昇順に並べ替えたいとき、文字列として扱われてしまう。
合計金額を計算したいとき、数値として扱えない。
逆に、名前を INTEGER にするのも不自然です。
「型を正しく選ぶ」というのは、後からの検索・集計・検証を楽にするための投資 です。
セキュリティの観点でも、型がきちんとしていると、「明らかにおかしい値」が入ってきたときに気づきやすくなります。
たとえば、年齢の列に極端に大きな数値が入っていたら、「これは何かの攻撃かもしれない」と疑うきっかけになります。
Day3 後半のまとめ
CREATE TABLE は、現実の情報を「列名＋型」という形に落とし込む作業。INTEGER と TEXT だけでも、ユーザー、商品、記事など多くのテーブルを設計できる。
定義したテーブルには、必ず一度は INSERT と SELECT を試して、「本当に動く」ことを体で覚える。
型を正しく選ぶことは、集計や検索を楽にし、セキュリティ的にも「おかしなデータ」に気づきやすくする。