스키마 설계

[JinhyeonKwak]

user는 매일 갱신되는 일정표에 자신의 운동 여부를 체크한다(혹은 매일 해야 되는 일 체크). 그리고 하루 소비 금액을 매일 기록하고, 한 달 동안의 지출 내역과 자신의 ToDo 체크 리스트를 이메일로 전송한다.

• User

  • user_id (pk)
  • 회원 정보 관련 필드

• Schedule

  • schedule_id (pk)
  • user_id (fk)
  • accout_id (fk)
  • 운동 여부
  • (운동 외에도 매일 해야 되는 일에 대한 필드)
  • 날짜 (date)

• Facility

  • facility_id (pk)
  • location (주소 혹은 위치에 대한 정보)
  • 종류 eg. 헬스장, 필라테스, 철봉 등
  • 해당 시설에 대한 코멘트

• Account

  • account_id (pk)
  • 하루 소비 금액
  • 사용처, 사용 시간 등의 필드

---

• Comment
  • (운동 시설에 대한 사용자의 댓글을 지속적으로 추가해야 한다면 필요)

[JinhyeonKwak]

수입에 대한 구현은 일별로 구현하는 것은 별로 의미가 없는 것 같고, 만약 구현해야 한다면 월별로 지출 내역과 비교하는 것이 더 실용적일 것이라고 생각되네요. 이 부분은 다시 논의해봐야 될 것 같습니다!

[iDevBrandon]

수입/지출 관련해서 데이터가 DB 테이블안에 있으면, 프론트에서 날짜별로 필터링 해서 작업할수 있을거 같습니다. 그래서 진현님 말씀처럼 따로 일별/월별 분리는 따로 필요없을거 같습니다

[hopee0411]

정리가 잘 된 것 같아서 제가 생각하는 추가 사항만 코멘트 달겠습니다.

[hopee0411]

security 사용 시 jwt 사용할 경우 token

• tokenId(pk)
• userId(fk)
• token

Schedule

• schedule_id (pk)
• user_id (fk)
• 년
• 월
• 일
• 전부 완료status(true, false)
• 하루 총 지출 금액
• 하루 총 수입 금액

ScheduleInfo

• scheduleInfoId(pk)
• schedule_id (fk)
• 운동,할일 등등 해야할 일
• type(운동, 스터디, 레슨 ..등등)
• 완료status (true, false)

Account

• account_id (pk)
• userId(fk)
• 년
• 월
• 일
• 시간
• 사용처
• type(지출, 수입)
• 금액

스케쥴은 하루에 여러개 등록할 수 있다고 생각해서 하루하루 날짜별 테이블 따로 잡고 스케쥴list 테이블 따로 잡는 게 어떨가 싶어요! account쪽에는 userId로 fk받아서 수입이든 지출이든 등록해서 날짜로 조회해서 가져오면 어떨까요??

년/월/일 은 한 필드에 있어도 되고 나눈 이유는 검색어 필터링 할 때 편하지 않을까 싶어서 나눴습니다

[JinhyeonKwak]

예상 시나리오 :

userA가 1월 1일에 대한 일정표(Schedule)를 만듭니다. (이 때, User는 하루에 Schedule을 하나만 생성할 수 있습니다) 그리고 할 일(DayWork)과 가계부(Account)를 생성합니다. 이를 Schedule이 참조할 수 있도록 합니다.

Schedule :

• id = 1
• userA
• 2023년 1월 1일
• Accounts (1 : N) -> List
• DayWorks (1 : N) -> List

Account :

• id = 1
• 사용 시간 : 13시 00분
• 사용 금액 : 1000원
• 사용처 : 편의점

DayWork :

• id = 1
• type : 운동
• content : 턱걸이 5세트
• status : false

---

정리해주신 내용을 바탕으로 다시 생각해보니 이런 식으로 하는 방법도 떠올랐습니다. 그리고 Schedule은 일정 관리만 해야 하므로 돈과 관련된 필드는 Account에서만 관리하는게 더 좋을 것 같습니다. 그리고 ScheduleInfo라는 테이블명이 아래 필드들의 성격을 더 구체적으로 반영했으면 좋을 것 같아 DayWork로 수정해보았습니다.

Schedule에서 Account를 참조하고 있는 이유는 만약 Account를 조회해야 하는 경우 userId와 날짜로만 조회해야 하는데, 이게 성능상 조금 나쁘지 않을까 하는 생각이 듭니다. 실제로는 어떨지 잘 모르겠네요..ㅎㅎ 그래서 핵심 도메인을 Schedule로 잡고 이 루트를 통해서만 Account와 DayWork로 접근하는 방향을 생각해보았습니다. 제가 혹시 잘못 생각한 부분이 있다면 피드백 부탁드리겠습니다!

아 그리고 jwt token은 제가 조금 더 공부해고 다시 말씀드리겠습니다. @hopee0411

[hopee0411]

제가 userId로 잘못적었네요 Schedule에서 Account를 참조하는 게 맞을 것 같아요/ Schedule에서 날짜별 총 수입, 지출을 관리한다면 맞을 것 같고, 총 수입, 지출도 따로 관리하겠다 라고 한다면 분리하는 게 맞을 것 같아요. 총 수입, 지출을 하루 날짜로 list 조회해서 계산하고 뿌릴 수도 있지만 성능상 수입, 지출이 들어올때마다 업데이트해서 select으로 꺼내오는 게 맞을 것 같아요!

token의 경우

1. refreshToken 까지 발급할 경우
   • accessToken 만료 시 refreshToken을 검증하는 과정에서 서버에 저장된 refreshToken 과 검증을 해야해서 테이블이 하나 필요할 것 같습니다.
2. accessToken만 발급할 경우
   • 만료 시 로그인으로 이동
   • 따로 서버에 저장된 토큰과 검증이 필요하지 않아 Token 테이블은 없어도 될 것 같습니다.

[hopee0411]