WebアプリのDB設計をレビューします

▼こんな方へおすすめです ・同じ枠が二人に予約されてしまったことがある ・決済のWebhookが再送されて、二重に反映されたことがある ・テーブルを増やしてきたが、正規化と制約が今のままでいいのか判断がつかない ・AIに書かせたスキーマをそのまま使っていて、根拠を説明できない ▼何をするか いただいたスキーマを読み、次の観点でレビューして改善案をお返しします。 ・制約とインデックスの過不足。どこにunique制約を置くべきか、どのクエリにindexが効くか ・同時更新で壊れうる箇所。在庫や予約枠のように「確認してから確保する」処理が競合しないか ・冪等性。同じリクエストやWebhookが二度届いたときに二重反映されないか ・金額や残高の持ち方。カラムで持つか、取引を積む台帳にするか ・マイグレーションの順序と、既存データを壊さない移行の手順 指摘は根拠つきで書きます。「こうすべき」だけでなく「なぜそうなるか」「代わりに何を捨てるか」まで書きます。 ▼私が実際に踏んだところ 音声通話マーケットプレイスを自分で設計・実装しています。Next.js / TypeScript / Prisma / Supabase / PostgreSQL、決済はStripe Connectを本番で通しています。スキーマは23モデル、マイグレーション8本です。 そのなかで、予約枠の二重取りをSerializableのトランザクションで防ぎ、StripeのWebhookはイベントIDのunique制約で冪等にし、金額は残高カラムを持たせず取引を一行ずつ積む台帳にしました。ここで書いているのは、本で読んだ話ではなく実際に直面して選んだ設計です。 ▼納品するもの ・レビューメモ（指摘・理由・優先度） ・改善後のER図とテーブル定義 ・マイグレーション案 ▼お受けできないこと ・本番データベースへのアクセス権をお預かりする形。スキーマの写しをいただければ十分です ・規約で自動アクセスが禁止されているサイトからのデータ取得を前提とした設計 ・医療や金融で、法規制の解釈そのものが判断の中心になる設計 ▼AIの利用について 実装やSQLの下書きには生成AIを使います。ただし、なぜこの正規化にしたか、なぜここに制約を置いたかは自分で決めて、自分の言葉で説明します。説明できない設計は出しません。