画面とDB設計をまとめよう

このページで学ぶこと

• 画面遷移図を書ける
• アプリのDBスキーマを設計してPrismaに落とし込める
• 実装前に設計をレビューする重要性がわかる

なぜ設計が重要か

「とりあえずコードを書き始めよう」は、あとで大変になりがちです。
設計段階で考えを整理しておくと、実装中に迷いが減ります。

設計せずに始めた場合によく起きること

• 「このデータ、テーブルに持たせておけばよかった」という後悔
• 途中でDB構造を変えると、既存のコードも大幅修正が必要になる
• 画面を作り始めてから「この遷移って必要だった？」となる

設計は30分〜1時間かけて、紙でもホワイトボードでも、ノートでもOKです。

画面遷移図を書く

どんな画面があって、どう繋がるかを図にします。

例：読書記録アプリの画面遷移

チェックリスト

• ログイン/サインアップページ
• データの一覧ページ
• データの詳細ページ（必要なら）
• データの追加フォーム
• データの編集フォーム（必要なら）

DB スキーマを設計する

「DBスキーマを設計しよう」で学んだ方法で、自分のアプリのスキーマを設計しましょう。

例：読書記録アプリのER図

Prismaスキーマに落とし込む

// prisma/schema.prisma
 
model User {
  id        String   @id  // Supabase Auth の UUID を使う
  name      String
  books     Book[]
  createdAt DateTime @default(now()) @map("created_at")
 
  @@map("users")
}
 
model Book {
  id        Int      @id @default(autoincrement())
  title     String
  author    String?  // ? をつけると任意項目になる
  memo      String?
  rating    Int?     // 1〜5の評価
  userId    String   @map("user_id")
  user      User     @relation(fields: [userId], references: [id])
  createdAt DateTime @default(now()) @map("created_at")
 
  @@map("books")
}

Supabase AuthのユーザーIDはUUID文字列
Supabase Auth が発行するユーザーIDは uuid 型です。
User モデルの id を String にして、Supabase Auth の ID をそのまま使うのが一般的です。

実装前のチェックリスト

メンターと一緒に確認しましょう。

確認しよう

• 画面遷移図（ラフでもOK）を書いた
• ER図を書いた
• Prismaスキーマを schema.prisma に書いた
• npx prisma migrate dev でテーブルを作成した
• メンターにレビューしてもらった

次のステップ

設計が終わったら実装フェーズに入ります。
次のページで、どこから手をつけるかを確認してから進みましょう。

→ 自分のアプリを実装しよう