계획대로 되지 않는 것이 인생

기본 시스템 구조도

사용자 로그인 방식은 OAuth로만.

사용자 별로 파티를 갖고 있으며, 파티에는 파티 호스트가 존재한다.

+ 사용자는 뱃지를 가지고 있음

파티 별로 챌린지가 존재하며, 챌린지 내에 사용자 별 세부 목표(타겟)이 존재한다.

파티 내에는 포스팅이 존재하며, 포스팅은 타겟과 챌린지를 갖는다.

코멘트를 통해 포스팅을 인증할 수 있다.

ERD

badge

user.badge

user

user.party

party

// 사용자 목록
Table user as U {
  id int [pk] //type 결정 필요
  user_id varchar //사용자 아이디
  name varchar //사용자 이름
  status varchar //사용자 상태
  created_at timestamp
  modified_at timestamp
}

// 사용자 - 뱃지 정보
Table user.badge as UB {
  id int [pk] //type 결정 필요
  user_id int //사용자 id
  badge_id int //뱃지 id
  created_at timestamp
  modified_at timestamp
}

// 뱃지 목록
Table badge as B { 
  id int [pk] //type 결정 필요
  name varchar //뱃지 이름
  description varchar //설명
  condition varchar //획득 조건 (form 지정 필요)
  created_at timestamp
  modified_at timestamp
}

// 파티 - 사용자 정보
Table user.party as UP {
  id int [pk] //type 결정 필요
  user_id int //사용자 id
  party_id int //파티 id
  party_alias varchar //파티 내에서 사용할 이름
  is_admin boolean //관리자 여부
  created_at timestamp
  modified_at timestamp
}

// 파티 목록
Table party as P {
  id int [pk] //type 결정 필요
  name varchar //파티 이름
  
  //입장관련
  party_code varchar //파티 코드
  question varchar //질문
  answer varchar //답변
  
  rules varchar //인증 룰 정보
  
  creater varchar //파티 생성자 
  created_at timestamp
  modified_at timestamp
 }

 Ref: UB.user_id > U.id
 Ref: UB.badge_id > B.id
 Ref: UP.user_id > U.id
 Ref: UP.party_id > P.id
 
// ----------------------------------------------
 
// 파티 관련 정보: 파티 단위 챌린지
Table party.challenge as PC {
  id int [pk]
  party_id int //파티 id
  name varchar //챌린지 이름
  description varchar //챌린지 설명

  start_at timestamp //챌린지 시작일
  end_at timestamp //챌린지 종료일
  
  created_at timestamp
  modified_at timestamp
}

 Ref: PC.party_id > P.id
 
// ----------------------------------------------
 
//유저 관련 정보: 개인 목표  
Table user.target as UT {
  id int [pk]
  name varchar //목표 이름
  description varchar //목표 설명
  
  party_id int //파티 id
  owner_id int //목표 소유자 id
  challenge_id int //생성 당시 파티 챌린지 id
  
  created_at timestamp
  modified_at timestamp
 }
  
// 유저 관련 정보: 인증
Table user.certification as UCE {
  id int [pk]
  is_ok boolean //인증 성공 여부
  post_id int //포스트 id
  granter_id int //인증 부여자 id
  
  party_id int //파티 id
  target_id int //개인 목표 id
  owner_id int //개인 목표의 사용자 id
  
  created_at timestamp
  modified_at timestamp
}

// 유저 관련 정보: 유저 포스팅
Table user.post as UPO {
  id int [pk]
  image varchar //이미지는 어떻게 저장하지 ???
  description varchar //포스팅 내용
  
  party_id int //파티 id
  owner_id int //글쓴 사용자 id
  target_id int //포스트가 속한 개인 목표 id
  
  created_at timestamp
  modified_at timestamp
 }
 
 // 유저 관련 정보: 코멘트
Table user.comment as UCO {
  id int [pk]
  title varchar //코멘트 제목 - 필요한지?
  description varchar //코멘트 내용
  
  party_id int //파티 id
  owner_id int //코멘트쓴 사용자 id
  post_id int //포스트 id
  certification_id int //코멘트에서 판단한 인증 id
  
  created_at timestamp
  modified_at timestamp
 }
 
 
 Ref: UT.party_id > P.id
 Ref: UT.owner_id > UP.id
 Ref: UT.challenge_id > PC.id

 Ref: UCE.party_id > P.id
 Ref: UCE.target_id > UT.id
 Ref: UCE.owner_id > UP.id
 
 Ref: UCE.post_id > UPO.id
 Ref: UCE.granter_id > UP.id
 
 Ref: UPO.party_id > P.id
 Ref: UPO.owner_id > UP.id
 Ref: UPO.target_id > UT.id
 
 Ref: UCO.party_id > P.id
 Ref: UCO.owner_id > UP.id
 Ref: UCO.post_id > UPO.id
 Ref: UCO.certification_id > UCE.id

 
//----------------------------------------------//

기본적으로 user Table을 기준으로 설계하였다.

유저 개인이 파티, 챌린지, 타겟 상관 없이 히스토리들을 볼 수 있었으면 좋겠다고 생각해서 되도록 하위 정보(post, comment, certification에 유저 정보들을 넣도록 설계하였다.