リレーションと外部キー

なぜ学ぶか： 「この投稿は誰が書いた？」「この進捗は誰のもの？」— テーブル同士のつながりがリレーション。user_idという列に「auth.usersのidが入る」と宣言するのが外部キーで、AIが生成するテーブル設計を読み解く最後のピースです。

リレーション＝テーブル同士のつながり

「誰の何か」を表すには、テーブルを分けてidでつなぎます。

外部キー＝つながりの宣言

user_id uuid references auth.users(id)は「この列には、実在するユーザーのidしか入らない」という制約。DBがデータの整合性を守ってくれます。

1対多が基本形

1人のユーザーが多数の投稿を持つ（1対多）。「多」の側（posts）に「1」のid（user_id）を持たせるのが定石です。

設計レビューの2大質問

「このテーブル、誰のデータか分かる？（user_idはあるか）」「つながりは外部キーで宣言されているか」— この2つから見ます。

SQLの例

-- 1人のユーザーが、多数の投稿を持つ（1対多）
create table posts (
  id uuid primary key default gen_random_uuid(),
  -- 外部キー: 実在するユーザーの id しか入らない
  user_id uuid references auth.users(id) not null,
  title text not null
);

-- RLS も忘れずに（前トピックの合言葉）
alter table posts enable row level security;

create policy "投稿は誰でも読める"
  on posts for select using (true);

using (true)は「全員OK」の意味 — 読みと書きで別のルールを持てるのがRLSの柔軟さです。「誰でも読めるが、書けるのは本人だけ」という公開ブログ型もこれで作れます。

ステップ 1 / 2

← カリキュラム一覧へ戻る

※ カリキュラムの内容はAIが生成しており、誤りが含まれる場合があります。正確な情報は公式ドキュメント等でご確認ください。