Open JinhyeonKwak opened 1 year ago
수입에 대한 구현은 일별로 구현하는 것은 별로 의미가 없는 것 같고, 만약 구현해야 한다면 월별로 지출 내역과 비교하는 것이 더 실용적일 것이라고 생각되네요. 이 부분은 다시 논의해봐야 될 것 같습니다!
수입/지출 관련해서 데이터가 DB 테이블안에 있으면, 프론트에서 날짜별로 필터링 해서 작업할수 있을거 같습니다. 그래서 진현님 말씀처럼 따로 일별/월별 분리는 따로 필요없을거 같습니다
정리가 잘 된 것 같아서 제가 생각하는 추가 사항만 코멘트 달겠습니다.
security 사용 시 jwt 사용할 경우 token
Schedule
ScheduleInfo
Account
스케쥴은 하루에 여러개 등록할 수 있다고 생각해서 하루하루 날짜별 테이블 따로 잡고 스케쥴list 테이블 따로 잡는 게 어떨가 싶어요! account쪽에는 userId로 fk받아서 수입이든 지출이든 등록해서 날짜로 조회해서 가져오면 어떨까요??
년/월/일 은 한 필드에 있어도 되고 나눈 이유는 검색어 필터링 할 때 편하지 않을까 싶어서 나눴습니다
예상 시나리오 :
userA가 1월 1일에 대한 일정표(Schedule)를 만듭니다. (이 때, User는 하루에 Schedule을 하나만 생성할 수 있습니다) 그리고 할 일(DayWork)과 가계부(Account)를 생성합니다. 이를 Schedule이 참조할 수 있도록 합니다.
Schedule :
Account :
DayWork :
정리해주신 내용을 바탕으로 다시 생각해보니 이런 식으로 하는 방법도 떠올랐습니다. 그리고 Schedule은 일정 관리만 해야 하므로 돈과 관련된 필드는 Account에서만 관리하는게 더 좋을 것 같습니다. 그리고 ScheduleInfo라는 테이블명이 아래 필드들의 성격을 더 구체적으로 반영했으면 좋을 것 같아 DayWork로 수정해보았습니다.
Schedule에서 Account를 참조하고 있는 이유는 만약 Account를 조회해야 하는 경우 userId와 날짜로만 조회해야 하는데, 이게 성능상 조금 나쁘지 않을까 하는 생각이 듭니다. 실제로는 어떨지 잘 모르겠네요..ㅎㅎ 그래서 핵심 도메인을 Schedule로 잡고 이 루트를 통해서만 Account와 DayWork로 접근하는 방향을 생각해보았습니다. 제가 혹시 잘못 생각한 부분이 있다면 피드백 부탁드리겠습니다!
아 그리고 jwt token은 제가 조금 더 공부해고 다시 말씀드리겠습니다. @hopee0411
제가 userId로 잘못적었네요 Schedule에서 Account를 참조하는 게 맞을 것 같아요/ Schedule에서 날짜별 총 수입, 지출을 관리한다면 맞을 것 같고, 총 수입, 지출도 따로 관리하겠다 라고 한다면 분리하는 게 맞을 것 같아요. 총 수입, 지출을 하루 날짜로 list 조회해서 계산하고 뿌릴 수도 있지만 성능상 수입, 지출이 들어올때마다 업데이트해서 select으로 꺼내오는 게 맞을 것 같아요!
token의 경우
user는 매일 갱신되는 일정표에 자신의 운동 여부를 체크한다(혹은 매일 해야 되는 일 체크). 그리고 하루 소비 금액을 매일 기록하고, 한 달 동안의 지출 내역과 자신의 ToDo 체크 리스트를 이메일로 전송한다.
User
Schedule
Facility
Account