Skip to content
Cocot Wiki

works / uploads / tags データモデル

なぜ works と uploads を分離しているか

ファイル変換のライフサイクル（uploading→transcoding→done/failed）と、投稿のライフサイクル（draft→publish_pending→published、deleted）は別物であるため、worksとuploadsを別テーブルにし、双方向FKでリンクしている。1

uploads テーブル

  • id (text, PK) = TUSアップロードID = Garageオブジェクトキー
  • user_id (Firebase UID)
  • original_key / converted_key (Garageオブジェクトキー)
  • original_size
  • status: upload_status enum — uploading → transcoding → done | failed
  • error_message
  • work_id (uuid, FK→works) — 004で追加

works テーブル

  • id (uuid, PK)
  • user_id
  • title (NOT NULL DEFAULT ”)
  • description
  • thumbnail_key
  • status: work_status enum — draft → publish_pending | published、他にdeleted
  • upload_id (FK→uploads)
  • published_at

双方向FKの理由

works.upload_idとuploads.work_idは同じ関係を逆方向から見たものだが、クエリ方向が異なるため両方持たせている:

  • app側「このユーザーの現在アップロード中のファイルはどれか」→works.upload_id
  • worker側「このアップロードはどの投稿に属するか」→uploads.work_id

tags / work_tags

  • tags: id (bigserial PK), name (text, UNIQUE)
  • work_tags: work_id + tag_idの複合PK、work_idはON DELETE CASCADE

タグ更新（PATCH /api/works/:id）は差分適用ではなく全置換方式。タグ名の正規化（大文字小文字・全角半角）は未確定事項として残っている。

Footnotes

  1. 音声投稿機能 設計書 ↩