設計レビュー
自分の設計を他人の目で見る
設計は書いた直後が一番見えません。作った本人は「そのつもり」で読んでしまうからです。
そこで観点表を使います。感想ではなく決まった順に確かめることで、見落としを減らします。実務のレビューも、この形で進めるのが普通です。
レビュー観点表
| # | 観点 | 見つかる不備 |
|---|---|---|
| 1 | 主キーはすべてのテーブルにあるか | 行を一意に指せない |
| 2 | 参照している列に外部キーがあるか | 存在しない相手を指す行が入る |
| 3 | 行を作る時点で決まる列に NOT NULL があるか | 値の無い行が入る |
| 4 | 業務上あり得ない値を CHECK で止めているか | 負の金額が入る |
| 5 | 重複してはいけない組み合わせに UNIQUE があるか | 二重登録が起きる |
| 6 | 同じ事実が2か所に書かれていないか | 更新不整合が起きる |
| 7 | 名前は規則どおりか | 読むたびに迷う |
上から順に見ます。思いついた順に見ない、というのが観点表の値打ちです。
一番見つかるのは NOT NULL の抜け
経験上、最も多く見つかるのが観点3です。CREATE TABLE を急いで書くと、NOT NULL は真っ先に抜け落ちます。
抜けたまま運用が始まると、あとから付けるのが難しくなります。すでに NULL の行が入っていたら、その行をどうするかを業務側と決めなければならないからです。レビューで拾えるかどうかが、そのまま将来の手間の差になります。
制約は「入れてみて」確かめる
観点表を通したら、わざと壊れたデータを入れてみます。設計どおりなら弾かれます。
弾かれるべきものが入ってしまったら、そこが抜けています。読み返すより確実です。第4章で ON CONFLICT DO NOTHING を使ったのと同じやり方で、エラーを出さずに確かめられます。
手を動かす
制約が抜け落ちたクーポン設計を、観点表に沿って直します。
テーブル構造
CREATE TABLE customers (
id integer PRIMARY KEY,
name text NOT NULL
);
CREATE TABLE orders (
id integer PRIMARY KEY,
customer_id integer NOT NULL REFERENCES customers (id),
total integer NOT NULL
);
CREATE TABLE coupons (
id integer PRIMARY KEY,
code text,
discount_amount integer,
expires_on date
);
CREATE TABLE coupon_usages (
id integer PRIMARY KEY,
coupon_id integer,
order_id integer,
customer_id integer,
discounted_amount integer
);
INSERT INTO customers VALUES (1, '田中あかり'), (2, '佐藤けんじ');
INSERT INTO orders VALUES (1, 1, 134400), (2, 2, 24000);
INSERT INTO coupons VALUES (1, 'SPRING2026', 1000, DATE '2026-06-30');
INSERT INTO coupon_usages VALUES (1, 1, 1, 1, 1000);
期待される出力
| constraint_type | cnt |
|---|---|
| CHECK | 1 |
| FOREIGN KEY | 3 |
| PRIMARY KEY | 2 |
| UNIQUE | 3 |