スキーマ設計の基本

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

「もの」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);

author_id ... REFERENCES users(id) の行が外部キーです。各投稿をちょうど1人の実在するユーザーに結びつけるので、データベース自身が有効な著者のない投稿を保存することを拒みます:

   users                          posts
   ┌─────────────┐                ┌─────────────┐
   │ id  (PK) ◀──┼────────────────┤ author_id   │  (FK → users.id)
   │ email       │  1ユーザーが    │ id  (PK)    │
   │ created_at  │  多くの投稿を   │ title       │
   └─────────────┘  持つ           │ body        │
                                   │ published   │
        1  ────────────────────▶  *└─────────────┘
       (1)                      (多)

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

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

スキーマ設計の基本

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