erDiagram
	user{
		bigint id PK "유저 id"
		bool login UK "로그인 여부"
		string(20) name UK "성함"
		int relation UK "촌수"
		int party_type UK "가족 관계"
		string email "이메일"
		bool proposition "성함 주격조사 0 : 은 이, 1 : 는 가" 
		string nick_name "애칭"
		bool nick_name_proposition "애칭 주격조사"
		bool in_game "게임 참가 여부"
	}
	party{
		bigint id PK "파티 id"
		int party_type "가족 관계"
		datetime created_at "생성 시간"
	}
	party_dashboard{
		bigint party_id FK "파티 id"
		bigint current_game_id FK "현재 게임"
		int current_game_stage "현재 게임 단계"
	}
	game{
		bigint id PK "게임 id"
		string name "게임 이름"
		string description "게임 설명"
		bool playable "플레이 가능 여부"
	}
	round{
		bigint party_id FK "파티 id"
		bigint id PK "라운드 id"
		bigint game_id FK "게임 id"
		int answer "정답"
		datetime created_at "생성 시간"
	}
	submission{
		bigint id PK "제출 id"
		bigint round_id UK "라운드 id"
		bigint user_id FK "유저 id"
		bigint number "숫자"
		string text "글자"
	}
	score{
		bigint party_id FK "파티 id 복합키"
		bigint user_id FK "유저 id 복합키"
		bigint score "종합 점수"
	}
	score_history{
		bigint user_id FK "유저 id"
		bigint party_id FK "파티 id"
		bigint round_id FK "라운드 id"
		bigint score "라운드 별 획득 점수"
	}
	party ||--|| party_dashboard : contains
	party_dashboard ||--|| game : "tracks current"
	party ||--o{ round : includes
	user ||--o{ submission : submits
	round ||--o{ submission : "is accosiated with"
	round ||--o{ score_history : generates
	score ||--o{ score_history : "is detailed in"
	
	game ||--|| round : "plays in"

---

ERD 구조

user: 사용자 정보
party: 게임 파티 정보
party_dashboard: 현재 파티 상태
round: 게임 라운드 정보
game: 게임 정보
submission: 사용자 제출 정보
score: 사용자 점수
score_history: 라운드별 점수 기록

주요 관계

user

• user와 submission: 1:N 관계 ("submits")

party

• party와 party_dashboard: 1:1 관계 ("contains")
• party와 round: 1:N 관계 ("includes")

round

• round와 submission: 1:N 관계 ("is associated with")
• round와 score_history: 1:N 관계 ("generates")

game

• game과 round: 1:1 관계 ("plays in")
• party_dashboard와 game: 1:1 관계 ("tracks current")

논리적 외래키

MSA로의 확장성을 고려하여 도메인 간 결합을 줄이기 위해
논리적 외래키만 사용하고 물리적 외래키를 사용하지 않습니다.

장점:
서비스 자율성 증가: 각 서비스가 자체 데이터 모델을 완전히 제어할 수 있습니다.
배포 용이성: 서비스 간 데이터베이스 종속성이 줄어 독립적인 배포가 가능합니다.
성능 최적화: 각 서비스에 맞는 데이터베이스 기술 선택이 가능합니다.

단점:
데이터 일관성 관리 복잡: 서비스 간 데이터 일관성을 애플리케이션 로직으로 관리해야 합니다.
쿼리 복잡성 증가: 여러 서비스의 데이터를 조합해야 하는 경우 쿼리가 복잡해질 수 있습니다.
데이터 중복: 일부 데이터가 여러 서비스에 중복 저장될 수 있습니다.

score 복합키

외래키가 아닌 이유

• MSA 원칙 준수:
  논리적 외래 키 사용으로 서비스 간 결합도를 낮추고 독립성을 유지합니다.

UNIQUE가 아닌 이유

• 데이터 무결성:
  복합키는 NULL값을 허용하지 않고 UNIQUE는 NULL값을 허용하는데
  party_id와 user_id는 항상 존재하므로 복합키로 데이터 무결성을 보장할 수 있습니다.
• 클러스터드 인덱스
  복합키는 클러스터드 인덱스가 생성되고
  UNIQUE는 비클러스터드 인덱스가 생성 됩니다.
  클러스터드 인덱스는 범위 검색과 연속된 데이터를 빠르게 검색할 수 있으며
  이는 특정 파티 내의 모든 사용자 점수를 조회하는 작업에서 성능상 이점을 제공합니다.
• 저장 공간 효율성:
  클러스터드 인덱스는 데이터 자체를 인덱스 순서대로 저장하므로,
  별도의 인덱스 구조가 필요 없어 저장 공간을 절약할 수 있습니다.
• 조인 성능:
  클러스터드 인덱스는 식별 관계에서 조인 성능이 우수합니다.
• 데이터 모델의 명확성:
  party_id와 user_id의 조합이 핵심 식별자임을 명시하며
  데이터 모델을 이해하고 관리하는 데에 도움이 됩니다.

score 관계

user와 score 간의 1:N 관계를 넣지 않은 이유

• 다중 관계 방지:
  user와 score 사이에 직접적인 1:다 관계를 표현하면, party와의 관계가 모호해질 수 있습니다.
  현재 구조는 사용자가 여러 파티에 참여할 수 있고, 각 파티마다 별도의 점수를 가질 수 있음을 명확히 합니다.
• ERD의 간결성:
  현재 구조는 필수적인 관계만을 표현하여 ERD의 가독성을 유지하고 있습니다.
  모든 관계를 명시적으로 표현하면 다이어그램이 복잡해질 수 있습니다.