Vidding 데이터 모델 명세

새 Supabase 프로젝트(vidding-re)에 처음부터 구축하는 스키마다. 기존 서비스의 스키마를 이어받지 않으며, 데이터 이관도 없다. 기준 문서: PRD · 기능 스펙

1. 설계 원칙

2. 전체 구조

users ─┬─< addresses
       ├─< auctions ─┬─< episodes ──< episode_likes
       │             ├─< auction_favorites
       │             └─── chat_rooms ──< messages
       ├─< points
       └─< notifications

3. 테이블 정의

3.1 users

role 컬럼이 없다. 이 스키마에는 사용자 유형 개념이 존재하지 않는다 (P1).

• point_balance가 잔액의 단일 출처다. points 테이블은 이력이며, 잔액을 합산해 구하지 않는다
• CHECK ≥ 0 으로 잔액이 음수가 되는 것을 DB에서 막는다

3.2 addresses

제약 — UNIQUE (user_id) : 사용자당 배송지 1개

목록 화면도 기본 배송지 개념도 없다. 하나뿐이므로 구분할 대상이 없다 (F12 3.3).

3.3 auctions

상태를 2개만 둔다 — OPEN / CLOSED. '마감 임박'은 end_at으로 계산하는 파생 상태이므로 저장하지 않는다 (P5).

입찰 포인트 컬럼이 없다. 입찰 단계는 전 서비스 공통 상수이므로 경매마다 저장하지 않는다.

1,000 → 1,500 → 2,000 → 2,500 → 3,000   (+500 단위, 상한 3,000)

주최자가 시작·최대 포인트를 정하지 않는다. 입력 항목이 줄고, 검증 규칙이 사라지고, 교환 비율이 항상 명확해진다. 낙찰은 어차피 공감이 결정하므로 잃는 것이 없다.

image_urls만 배열을 유지한다. 순서가 의미를 갖고 동시 수정 주체가 주최자 한 명이라 P3의 문제가 발생하지 않는다.

3.4 episodes

제약

주최자 배제는 애플리케이션과 RLS에서 처리한다 (§6).

created_at은 낙찰 동점 기준이다 (F5 3.2.1). 수정해도 갱신하지 않는다.

3.5 episode_likes

제약 — UNIQUE (episode_id, user_id) : 한 사람이 한 사연에 한 번만

weight를 저장하는 이유

가중치를 코드 상수로만 두면, 나중에 값이 바뀌었을 때 공감 해제 시 다른 값이 차감된다. 부여 시점 값을 함께 저장해 F4 완료 조건 3(적용된 가중치와 같은 값 차감) 을 구조적으로 보장한다.

3.6 auction_favorites

제약 — UNIQUE (auction_id, user_id)

찜은 개인 북마크다. 찜 수를 공개하지 않으며 정렬·순위에 쓰지 않는다 (F7). 인기순 정렬 기준은 모인 사연 수다.

3.7 points

포인트 원장(ledger) 이다. 한 번 쌓인 행은 수정·삭제하지 않는다 (P4).

type 값

낙찰자에게는 정산 행이 추가되지 않는다. 입찰 시점의 BID 차감이 그대로 확정된다.

amount와 users.point_balance는 같은 트랜잭션에서 함께 갱신한다 (§4).

포인트 순환 구조

물건을 나누면 포인트를 얻고, 물건을 받으면 포인트를 쓴다.

[받는 쪽]  사연 낙찰  →  건 포인트가 차감 확정
                            ↓  이전
[주는 쪽]  경매 낙찰  →  낙찰자가 건 포인트를 수취

총량이 보존된다. 낙찰 순환에서는 포인트가 생기거나 사라지지 않고 이동만 한다. 신규 발행은 SIGNUP_BONUS 하나뿐이다.

자전거래가 구조적으로 불가능하다. 주최자는 자기 경매에 사연을 쓸 수 없으므로(F3), 자기 경매에서 자기에게 포인트를 보낼 수 없다.

3.8 chat_rooms

참여자 컬럼이 없다.

채팅은 낙찰 이후 주최자와 낙찰자 사이에서만 열린다 (F6). 두 사람 모두 경매에서 도출된다.

주최자  = auctions.user_id
낙찰자  = episodes.user_id  (auctions.winning_episode_id 가 가리키는 사연)

기존 스키마의 seller_id / buyer_id에 해당하는 컬럼이 필요 없다. 참여자를 별도로 저장하면 경매 데이터와 어긋날 수 있으므로 도출한다 (P2).

채팅방은 낙찰 확정 시에만 생성한다. 유찰된 경매에는 만들지 않는다.

3.9 messages

read_at이 NULL이면 읽지 않은 메시지다. 별도 플래그를 두지 않는다.

3.10 notifications

type 값

마감 임박을 단계별 type으로 나눈 이유가 아래 인덱스다. 하나의 값으로 두면 (사용자, 종류, 경매)당 1건 제한에 걸려 단계마다 보낼 수 없다. AUCTION_ENDING_SOON_% 접두어로 임박 알림 여부를 판정한다 (F9 3.4 경고색).

중복 방지 — 같은 사건에 대한 중복 발송을 막기 위해 부분 유니크 인덱스를 둔다 (F9).

UNIQUE (user_id, type, auction_id)
  WHERE type IN ('AUCTION_ENDING_SOON_3D','AUCTION_ENDING_SOON_1D',
                 'AUCTION_ENDING_SOON_1H','AUCTION_RESULT')

CHAT_MESSAGE는 반복 발생하므로 이 제약에서 제외한다.

단계마다 1건이다. 한 경매에 대해 한 사람이 같은 단계의 알림을 두 번 받지 않는다. 크론이 5분마다 돌아도 이 인덱스가 중복을 막으므로, 반복 실행이 곧 재시도가 된다.

푸시 알림을 만들지 않는다. 알림은 서비스 안에서만 확인한다 (F9).

4. 트랜잭션이 필요한 처리

다음 처리는 여러 테이블을 원자적으로 바꾼다. 각각 DB 함수(RPC)로 구현한다.

4.1 포인트 입찰 place_bid(episode_id, new_amount)

하나라도 실패하면 전부 롤백한다.

4.2 마감 처리 close_auction(auction_id)

1~6은 한 트랜잭션이다. 마감됐는데 낙찰자가 없는 중간 상태를 만들지 않는다 (F5). 7(알림)은 실패해도 롤백하지 않는다 (F5·F9).

포인트 총량 검증 — 3번(반환)과 4번(이전)의 합이 해당 경매의 BID 차감 총액과 정확히 일치해야 한다. 트랜잭션 종료 시 이 등식이 깨지면 롤백한다.

4.3 사연 삭제 delete_episode(episode_id)

4.4 공감 toggle_episode_like(episode_id)

점수를 직접 더하거나 빼지 않는다. 최종 점수는 §5의 뷰에서 집계하므로 연타·동시 조작으로 값이 어긋날 수 없다 (F4 완료 조건 6).

5. 뷰

5.1 v_episode_scores — 사연 최종 점수

episode_id
auction_id
user_id
bid_amount              -- 본인이 건 포인트
like_weight_sum         -- 받은 공감 가중치 합
total_score             -- bid_amount + like_weight_sum
like_count
created_at              -- 동점 판정용

낙찰자 선정과 랭킹 표시 모두 이 뷰를 쓴다.

ORDER BY total_score DESC, created_at ASC

F5 3.2.1의 동점 기준이 이 정렬 하나로 표현된다.

5.2 v_auction_summary — 목록·카드용

auction_id, title, thumbnail, end_at, status
episode_count           -- 모인 사연 수 (인기순 기준)
top_score               -- v_episode_scores 최고점

정렬 기준을 모두 이 뷰에서 처리한다 (F2).

찜 수는 이 뷰에 포함하지 않는다. 공개 지표가 아니다.

6. RLS 정책

관계 판정을 DB에서 강제한다 (P6). 00-관계-판정 4절의 "클라이언트 판정과 서버 판정이 다르면 서버를 최종으로 한다"가 여기서 보장된다.

핵심 정책 두 가지

-- 주최자는 자기 경매에 사연을 쓸 수 없다 (F3)
episodes INSERT:
  auth.uid() <> (SELECT user_id FROM auctions WHERE id = auction_id)

-- 채팅은 주최자와 낙찰자만 (F6)
chat_rooms SELECT:
  auth.uid() IN (
    (SELECT user_id FROM auctions WHERE id = auction_id),
    (SELECT e.user_id FROM auctions a JOIN episodes e ON e.id = a.winning_episode_id
      WHERE a.id = auction_id)
  )

7. 기존 스키마 대비 주요 변경

7.1 배열 → 조인 테이블 (가장 중요한 변경)

왜 바꾸는가

배열은 통째로 읽어서 통째로 쓴다. 두 사람이 동시에 공감을 누르면 나중 요청이 앞선 요청을 덮어쓴다.

A 읽기 [x]  →  A 쓰기 [x, A]
B 읽기 [x]  →  B 쓰기 [x, B]     ← A의 공감이 사라진다

기존 서비스가 "클릭 시점에 최신 값을 다시 조회한다"는 우회 처리를 두었던 이유가 이것이다. 조인 테이블 + UNIQUE 제약으로 바꾸면 삽입·삭제만으로 끝나고 경합 자체가 사라진다.

F4·F7의 "연타·동시 조작에도 값이 어긋나지 않는다" 완료 조건이 구조로 해결된다.

7.2 그 외

8. 인덱스

episodes의 UNIQUE (auction_id, user_id)는 제약이자 참여자 관계 판정용 인덱스다. 경매 상세에 들어갈 때마다 이 조회가 발생한다 (00-관계-판정 3.2).

9. 마감 처리 실행

auctions.end_at이 지난 경매를 주기적으로 찾아 close_auction()을 호출한다.

화면에서는 end_at이 지나면 처리 완료 전이라도 마감 상태로 표시하고 참여 액션을 차단한다 (F5 예외 처리).

10. 포인트 경제 요약 — 확정

가입 보너스 지급 방식

SIGNUP_BONUS는 가입 시점 트리거로 지급한다. 스케줄러(크론)로 처리하지 않는다.

크론은 실행 주기만큼 지급이 늦어져, 가입 직후 첫 참여 시 포인트가 없는 상태가 발생할 수 있다. 1회성 지급은 사건이 일어난 시점에 처리한다.

11. 고정 상수

코드가 아니라 여기가 단일 출처다. 값이 바뀌면 이 표를 먼저 고친다.

11.1 입찰

11.2 공감 가중치

11.3 경매 기간

마감 임박 알림 — 단계

단계는 3일 · 1일 · 1시간 셋으로 고정이다. 경매마다 분기하지 않고, 경매 전체 기간보다 짧은 단계만 보낸다는 규칙 하나로 결정된다.

기간과 같거나 긴 단계를 제외하는 이유 — 3일 경매에 '3일 전' 단계를 허용하면 등록되는 순간 발송된다. 임박이라는 말이 의미를 잃는다.

단계를 지난 뒤 참여한 사람에게는 그 단계를 보내지 않는다.

episodes.created_at < auctions.end_at - 단계

마감 임박 알림은 잊고 있을 수 있는 사람을 깨우는 것이다 (F9 2). 방금 사연을 쓴 사람은 마감이 임박한 것을 이미 알고 있으므로 깨울 대상이 아니다. 마감 30분 전에 참여한 사람에게 "1시간 전이에요"를 보내면 문구도 사실과 다르다.

episodes.created_at은 수정해도 갱신하지 않으므로(F5 3.2.1) 기준으로 삼기에 안전하다.

한 번에 한 단계만 보낸다. 정상 운영에서는 단계마다 스케줄러가 먼저 처리하므로 겹치지 않지만, 스케줄러가 며칠 멈췄다 재개하면 한 사람이 세 단계를 동시에 만족한다. 그때 "3일 전이에요"를 30분 전에 보내지 않도록 가장 급한 단계 하나만 고른다.

11.4 글자 수

경매 쪽은 DB 가 btrim(...) > 0 만 강제한다. 상한은 애플리케이션이 지킨다. 사연과 달리 하한을 2자·5자로 올리지 않은 것은, 제목이 물건 이름 한 글자여도 말이 되기 때문이다 (F1 4.2 는 "길이 초과"만 요구한다).

11.5 이미지

경매 삭제 시 해당 이미지도 함께 정리한다.

11.6 마감 처리