スキーマ設計の基本

スキーマ はあなたのデータの設計図です。どんなテーブルがあり、どんなカラムを持ち、それらがどう関係するか。良いスキーマ設計は、ほとんどが常識といくつかの習慣です。

「もの」1つにつき1テーブル。 ユーザー、投稿、注文 — それぞれが自分のテーブルを持ちます。
すべての行に一意のIDが要る (主キー)。
テーブルは外部キーでリンクする。データをあちこちにコピーするのではなく。
正直な型を選ぶ。 お金は float ではなく decimal。日付はテキストではなくタイムスタンプ。
重複させない。 ユーザーのメールアドレスが5つのテーブルに住んでいたら、いずれ5つの異なるメールアドレスを持つことになります。

ブログ向けのシンプルなスキーマです。AIがあなたのために生成する類いのものです。

CREATE TABLE users (
    id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email       TEXT NOT NULL UNIQUE,
    created_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE posts (
    id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    author_id   UUID NOT NULL REFERENCES users(id),
    title       TEXT NOT NULL,
    body        TEXT NOT NULL,
    published   BOOLEAN NOT NULL DEFAULT false,
    created_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX idx_posts_author ON posts(author_id);

REFERENCES (投稿を実在するユーザーに結びつける外部キー) と、NOT NULL および UNIQUE 制約に注目してください。これらはデータベースがあなたのために強制してくれるガードレールで、コードにバグがあっても不正なデータが忍び込めないようにします。

意図的に加える価値のある制約は、親が消えたときに何が起こるかです。デフォルトでは、まだ投稿が参照しているユーザーを削除しようとすると失敗します — それがしばしばあなたの望むことです。しかし明示的に決められます: REFERENCES users(id) ON DELETE CASCADE は投稿も一緒に削除し、ON DELETE RESTRICT は削除を阻止します。意図を持って選ぶほうが、本番でデフォルトを痛い目で知るよりましです。同じ「データベースに自分を守らせる」本能は CHECK 制約 (CHECK (price >= 0)) にも当てはまります — すべてのコードパスが検証してくれると信じる代わりに、ばかげたデータを源泉で拒みます。

スキーマ設計の基本

オフラインでも読みたい？