SQL：テーブル設計とCREATE TABLE

itemsテーブルが作成される

CREATE TABLE items (id INTEGER PRIMARY KEY, name TEXT NOT NULL, price INTEGER);

CREATE TABLE items (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  price INTEGER
);

これがテーブル設計の最小形。列名・型・制約をカンマで区切って並べる。id を PRIMARY KEY にすると、SQLiteでは自動採番の主キーになる。

解答 == B

NOT NULL は「空を許さない」制約。

B

制約違反はエラーとして即座に拒否される。データが不正な状態のままテーブルに入ることはない。

membersテーブルが作成される

email TEXT UNIQUE のように、型の後ろに制約を書く。

CREATE TABLE members (
  id INTEGER PRIMARY KEY,
  email TEXT UNIQUE
);

UNIQUE を付けると、同じ値を2回挿入できなくなる。会員登録でメールアドレスの重複を防ぐのに使われる、実務で最も身近な制約の1つ。

CREATE TABLE members (
  id INTEGER PRIMARY KEY,
  status TEXT ____ '有効'
);

membersテーブルが作成される

「既定値」を意味する7文字のキーワード。

DEFAULT

DEFAULT を指定すると、INSERTで値を省略したときに自動で入る。会員登録時にステータスを毎回書かなくても「有効」が入る。

解答 == B

「捨てる」という意味の英単語。

B

DROP TABLE はテーブルの構造ごと消す。DELETEは行だけを消すが、DROPは列の定義もテーブル自体も消える。WHEREでは絞れない。

itemsテーブルが作成される

price INTEGER CHECK (price >= 0) のように書く。

CREATE TABLE items (
  id INTEGER PRIMARY KEY,
  price INTEGER CHECK (price >= 0)
);

CHECK は任意の条件を指定できる制約。負の価格や、範囲外の年齢など、業務ルールをテーブルの定義そのものに埋め込める。

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  customer_id INTEGER ____ customers(id)
);

ordersテーブルが作成される

「参照する」を意味する9文字のキーワード。

REFERENCES

REFERENCES で外部キーを設定する。これにより、存在しない顧客IDを注文に登録することを防げる（外部キー制約が有効な設定の場合）。

解答 == B

SQLiteの型システムは他のDBと比べて緩い。

B

SQLiteは「動的型付け」と呼ばれる方式で、型の定義があっても厳密には強制しない。MySQLやPostgreSQLではエラーになることが多く、環境によって挙動が違う点に注意が必要。

inventoryテーブルが作成される

CHECKとDEFAULTを両方、stock列に付ける。順番は CHECK と DEFAULT のどちらが先でもよい。

CREATE TABLE inventory (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  stock INTEGER DEFAULT 0 CHECK (stock >= 0)
);

1つの列に複数の制約を重ねられる。DEFAULTで「省略時は0」、CHECKで「負の値は拒否」——2つを組み合わせることで、在庫が常に0以上の整数であることが保証される。

logsテーブルが削除される

DROP TABLE logs; と書く。

DROP TABLE logs;

DROP TABLEはバックアップが無い限り取り消せない。実務では「本当にこのテーブルを消してよいか」を必ず複数人で確認してから実行する。

membersテーブルが作成される

各列に適切な制約を1つずつ組み合わせる。

CREATE TABLE members (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  email TEXT UNIQUE,
  joined_at TEXT
);

会員登録フォームの裏側で動いているテーブルそのもの。名前を必須にし、メールを一意にする——これだけで「名前未入力」「メール重複登録」という2つの事故を仕組みで防げる。

order_itemsテーブルが作成される

quantity に CHECK と DEFAULT を組み合わせる。

CREATE TABLE order_items (
  id INTEGER PRIMARY KEY,
  order_id INTEGER NOT NULL,
  product_id INTEGER NOT NULL,
  quantity INTEGER DEFAULT 1 CHECK (quantity >= 1)
);

数量が0や負の値になることを、テーブル自体が拒否する。アプリ側のチェックが漏れていても、データベースが最後の砦として守ってくれる。

reviewsテーブルが作成される

CHECK (rating >= 1 AND rating <= 5) のように範囲を指定する（SQL03のANDを思い出す）。

CREATE TABLE reviews (
  id INTEGER PRIMARY KEY,
  product_id INTEGER REFERENCES products(id),
  rating INTEGER CHECK (rating >= 1 AND rating <= 5),
  comment TEXT
);

SQL03で学んだANDが、CHECK制約の中でも使える。星1〜5段階のレビュー機能は、まさにこの制約で不正な評価点を防いでいる。

SQLiteでは挿入が成功する（型が緩いため）

CREATE TABLEしてからINSERTする。2本のSQLを書く。

CREATE TABLE items (
  id INTEGER PRIMARY KEY,
  price INTEGER
);

INSERT INTO items (price) VALUES ('abc');

SQLiteではこれが成功してしまうことがある。型を書いたからといって、それだけでデータの正しさは保証されない。CHECK制約やアプリ側の検証が別途必要になる理由がここにある。

products_v2テーブルが作成される

5つの列それぞれに適切な制約を組み合わせる。price は NOT NULL と CHECK の両方を付ける。

CREATE TABLE products_v2 (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  category TEXT DEFAULT '未分類',
  price INTEGER NOT NULL CHECK (price >= 0),
  stock INTEGER DEFAULT 0 CHECK (stock >= 0)
);

これまで扱ってきた products テーブルより、はるかに堅牢な設計になっている。SQL05で悩まされたNULLだらけのデータは、最初からこの制約があれば生まれなかった——制約は「後から直す」よりも「最初から防ぐ」ための道具だと分かる。